...

...

Compatibility headers (in boost\compatibility\cpp_c_headers) don't compile with BCB 6.4.

...

I'm confused why you would be using those - Borland supplies the new style headers with everything in namespace std already doesn't it?

Here's our problem,

In the serialization library there are 14 files that use functions from the std namespace. In order to compile these under VC 6.0 ( and perhaps other platforms ) we specify:

#include <boost/compatibility/cpp_c_headers/cstring> // memcpy

This resolves the issue with vc 6.0 ( and who knows who else ? maybe STLPort ? ). Conformant compilers don't seem to be affected adversely by this. The code itself uses a standard "std::memcpy" and everything is pretty clean.

Now comes along Borland - the files ccp_c_headers won't compiler here. So now we're in a quandary.

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 If you have a lot of files that need to do this, then the normal practice is to create your own private config header that contains that code. John.