"John Maddock" wrote:
BOOST_NO_STDC_NAMESPACE is not defined for the compiler but it should. This will immediatelly help with Serialization and possibly other libraries.
Are you talking about DMC without STLport? Surely it's unusable in that state as there's no std lib?
Several libraries (e.g. Type Traits) could be updated to handle this problem, e.g. with:
#include <cstddef> // std::size_t
#include <boost/config.hpp> #if defined(BOOST_NO_STDC_NAMESPACE) #error namespace std{ using ::size_t; } // namespace std #endif
Unnecessary, Boost.Config already has that workaround for common defs like size_t and ptrdiff_t.
When such workarounds are applied and the latest STLport (5.10 beta, supporting DMC) are used quite a many libraries get usable under dmc: Optional, Variant, Program Options, etc among others.
Oh, but when I compile the Boost.Config tests with the latest DMC and STLport-4.6.3 (the one that ships with DMC) all the config tests pass (except for an internal error in config_test.cpp: the individual tests pass). Which would indicate that no defines are required: in any case doesn't STLport do the importing of names into namespace std for us?
I see. It shows up when (a) no STL is used (one may work with Ultima++) or (b) the STL doesn't "hijack" the <cstddef> like headers. It is needed to manually set up use of STLport, by default the unadulterated <cstddef> is used with the effect above. The Config may catch the (a) by: #include <cstddef> #ifndef _STLP_CSTDDEF // STLport is not used, the <cstddef> may be the one // from DMC distribution, without using std:: namespace. // If another STL is used update accordingly. # define BOOST_NO_STDC_NAMESPACE #endif -------------- The Config may also add: #define BOOST_HAS_MS_INT64 (in DMC for long time, possibly for years) __int64 is alias for "long long", not standalone type (the same as say for Intel C++). ------------ The #define BOOST_HAS_WINTHREADS should be replaced with: #ifdef _MT # define BOOST_HAS_WINTHREADS # define BOOST_HAS_THREADS #endif ------------ /Pavel