Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c++ > #89

Re: Improving C and C++ header compatibility

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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