[Config] Digital Mars and BOOST_NO_STDC_NAMESPACE
Digital Mars C++ (as in latest version 8.49.1) doesn't insert items from files like <cstdef> into std:: namespace (the headers do not use namespaces at all). BOOST_NO_STDC_NAMESPACE is not defined for the compiler but it should. This will immediatelly help with Serialization and possibly other libraries. 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 or with: #include <boost/config.hpp> #ifdef BOOST_NO_STDC_NAMESPACE # include <boost/compatibility/cpp_c_headers/cstddef> #else # include <cstddef> #endif 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. /Pavel
Pavel Vozenilek wrote:
Digital Mars C++ (as in latest version 8.49.1) doesn't insert items from files like <cstdef> into std:: namespace (the headers do not use namespaces at all).
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? John.
"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
Pavel Vozenilek wrote:
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
I didn't quite do it like that (I used the STLPort feature detection macros, but it's in cvs now.
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++).
Unnecessary since we have long long support enabled, and it fails the config tests anyway.
The #define BOOST_HAS_WINTHREADS
should be replaced with:
#ifdef _MT
# define BOOST_HAS_WINTHREADS # define BOOST_HAS_THREADS #endif
Defining BOOST_HAS_THREADS here is unnecessary - it gets figured out later on. Isn't the test for _MT wrong as well: as far as I can tell dmc always supports threads on Win32 ? There certainly appear to be no compiler options that effect threading. I've added the math function macro's BOOST_HAS_EXPM1/BOOST_HAS_LOG1P. John. John.
"John Maddock" wrote:
The Config may catch the [not using STLport] by:
[ snip ]
I didn't quite do it like that (I used the STLPort feature detection macros, but it's in cvs now.
A complete test would check for Dinkumware, Rogue Wave and so on. But for STLport (5.10) it works and this is the only implementation that "oficially" supports DMC, AFAIK.
#ifdef _MT ....
Isn't the test for _MT wrong as well: as far as I can tell dmc always supports threads on Win32 ? There certainly appear to be no compiler options that effect threading.
Yes, my fault. MT is always on. /Pavel
The Config may also explicitly add: #define BOOST_HAS_EXPM1 #define BOOST_HAS_LOG1P for DMC. DMC claims (incomplete) C99 compatibility but it doesn't define the __STDC_VERSION__ correctly (or in line with Boost expectation). These functions are present /at least/ since 8.47. /Pavel
participants (2)
-
John Maddock -
Pavel Vozenilek