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

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

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?
As I said, some compilers shipped without those headers *at all*, that was all the compatibility headers were for IMO. John.
participants (2)
-
John Maddock
-
Robert Ramey