Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| Message-ID | <9047h7Fjv6U3@mid.individual.net> (permalink) |
|---|---|
| Newsgroups | comp.std.c++ |
| From | Ian Collins <ian-news@hotmail.com> |
| Subject | Re: Improving C and C++ header compatibility |
| Organization | unknown |
| References | <dc6a77fd-33e0-440e-bad5-3719104ab757@x18g2000yqe.googlegroups.com> <8vcfv2F532U1@mid.individual.net> <e376aa88-be0d-4e2f-b9f2-2bd64d275598@hd10g2000vbb.googlegroups.com> |
| Date | 2011-04-07 01:29 -0600 |
On 04/ 3/11 03:24 AM, Richard Smith wrote: > > [Again, my first reply to this hasn't reached the newsgroup.] > > On Mar 29, 8:07 pm, Ian Collins<ian-n...@hotmail.com> wrote: Francis address the first point. >> 4) In C, the restrict keyword (might) allow the compiler to make >> >>> better more assumptions about the two arguments and therefore optimise >>> it better; it also potentially allows for a compiler warning if the >>> same argument is supplied for both parameters. So far as I'm >>> concerned, the jury's still out as to whether this really does make a >>> significant improvement, but it's reasonable to assume a library >>> author might want to add it to the function. This means adding >>> another MYLIBRARY_RESTRICT macro as restrict is not permitted in C++. >> >> You shouldn't have to do this. Your environment should take care of this >> for you. Consider the system and C standard libraries which use restrict. > > I'm not sure I understand what you're saying. Consider the following > header: What I'm saying is I misunderstood your point! Checking my system (Solaris) headers, they have #if (defined(__STDC__) && defined(_STDC_C99)) #define _RESTRICT_KYWD restrict #else #define _RESTRICT_KYWD #endif Which is similar to what you proposed. >> 6) Finally, we may need some platform-specific code to make shared >> >>> libraries work, for example, on Window's we're likely to want to place >>> __declspec(dllimport) before each declaration in the header. This >>> needs wrapping in a macros, say MYLIBRARY_API, so that it's only used >>> in the appropriate places. >> >> This isn't a general problem (it certainly isn't on Unix and Unix like >> systems). > > So? > > It may only be a minority of systems that require such things, but the > Windows DLL model is an important special case. May be, but special cases are not something that is standardised. >>> Any thoughts? The changes are all minimal and unlikely to break >>> anything. It's too late now for C++0x, sadly, but they certainly >>> seem worth considering for the next version (or a TR if there's an >>> appropriate one). >> >> The only real language smell is boolean compatibility and declaration. >> Assuming _Bool and bool are compatible, this really boils down to the C >> problem of mixing C99 and C95 code. > > No. It's completely different. Mixing C99 with earlier versions of C > is a temporary problem. At some point you decide to abandon support > for earlier versions of C. At the moment, it may still makes sense to > assume that not all compilers support _Bool, in which case a > MYLIBRARY_BOOL macro that expands to either _Bool or int makes sense. > But once the library authors decide they no longer care about pre-C99 > compilers, the MYLIBRARY_BOOL macro no longer has a use in C. And in > my experience, C programmers are *far* more likely to care about > supporting old dialects of C than they are to support C++. So once > MYLIBRARY_BOOL no longer has a use for C compatibility, it will > frequently vanish, breaking C++; the same applies to > MYLIBRARY_RESTRICT. But surly these are issues for the operating system implementers, not the language standard? -- Ian Collins [ comp.std.c++ is moderated. To submit articles, try posting with your ] [ newsreader. If that fails, use mailto:std-cpp-submit@vandevoorde.com ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Back to comp.std.c++ | Previous | Next — Previous in thread | Next in thread | Find similar
Re: Improving C and C++ header compatibility Ian Collins <ian-news@hotmail.com> - 2011-03-29 13:07 -0600
Re: Improving C and C++ header compatibility Richard Smith <richard@ex-parrot.com> - 2011-04-02 09:24 -0600
Re: Improving C and C++ header compatibility Francis Glassborow <francis.glassborow@btinternet.com> - 2011-04-03 09:28 -0600
Re: Improving C and C++ header compatibility Ian Collins <ian-news@hotmail.com> - 2011-04-07 01:29 -0600
Re: Improving C and C++ header compatibility Richard Smith <richard@ex-parrot.com> - 2011-04-09 01:25 -0600
Re: Improving C and C++ header compatibility Francis Glassborow <francis.glassborow@btinternet.com> - 2011-04-09 10:17 -0600
csiph-web