Re:Re: Re:Re: [boost] [compatibility headers] fixes for Borland

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-03-12 13:28:31

John Maddock wrote:

>>  Robert Ramey wrote:
>>  a) Sprinkle #ifdef BORLAND in those 14 files
>>  b) Tweak cpp_c_headers files
>>  c) Or ? what?
>> 
>>  What is the least worst way to handle this?
>> 
>>  If I have to use a) what is the point of even having cpp_c_headers?

>Here's the problem: those headers were only supplied as a workaround for
>compilers that don't supply new style headers at all, they all use the
>following workaround:

>#include <string.h> 

>namespace std{ using ::memcpy; } //etc

>However for conforming compilers this is defective for two reasons:

>It needlessly introduces C functions into the global namespace (including
><cstring>  should not do that).
>It shouldn't compile at all: memcpy is already declared in std, the version
>in the global namespace is an alias introduced with a using declaration,and
>importing it back into std *should fail*.

>Now the interesting thing is, I know of only two vendors who are shipping
>std conforming C headers: Borland and Metrowerks.  Since you don't mention
>the latter my guess is you're not testing with it ;-)

>The normal workaround that Boost libs have been using is:

>#include <cstring> 
>#include <boost/config.hpp> 
>#ifdef BOOST_NO_STDC_NAMESPACE
>namespace std{ using ::memcpy; }
>#endif

OK, I can live with this. But if cpp_c_headers has conditioned on the
compiler then what is the point of having it all?  What use can it have?

Robert Ramey