Re: [boost] config/conformance issue

From: Ed Brey (brey_at_[hidden])
Date: 2000-06-05 12:17:53

From: "Beman Dawes" <beman_at_[hidden]>
>
>  #     define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
>  #     define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
> -#     define BOOST_NO_STDC_NAMESPACE
> +
> +#     ifndef __SGI_STL_PORT
> +#       define BOOST_NO_STDC_NAMESPACE
> +#     endif
> +
>  #   endif
>  #   if defined BOOST_DECL_EXPORTS
>  #     define BOOST_DECL __declspec(dllexport)

There are a couple of problems with this.  One is that the macros for
the standard library implementation may have not yet been defined.
Also, with that the latest stable release of STLport (3.2.1) doesn't
perform the workaround to pull names into namespace std by default.

For example, take this test program compiled with VC6 SP3 and STLport
3.2.1:

#define __STL_IMPORT_VENDOR_CSTD
#include <cstddef>

int main() {
 std::size_t s = 10;
 return s;
}

It works.  But if you comment out the __STL_IMPORT_VENDOR_CSTD
definition, you get the error that size_t is not a member of stlport
(std is #defined to stlport by default).  So if a user is using
STLport in out-of-the-box mode, the std namespace will still be
missing size_t from a boost library's perspective.

This should solve the problem:

# elif defined _MSC_VER && !defined __ICL
#   if _MSC_VER <= 1200  // 1200 == VC++ 6.0
...
#     define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
#     define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION

/* Make sure at least one standard library header is included so that
library implementation detection will work, even if no standard
headers
have been included in front of a boost header. */
#     include <cstddef>

/* Determine whether the standard library implementation is already
taking care of pulling names into std.  STLport defines the
following if so. */
#     ifndef __STL_IMPORT_VENDOR_CSTD
#       define BOOST_NO_STDC_NAMESPACE
#     endif

#   endif
...
# endif // Microsoft (excluding Intel/EDG frontend)

In version 4 beta 6 of STLport, the default is to pull names into std
by default, so the above example works even with the line
__STL_IMPORT_VENDOR_CSTD commented out.  The macro name didn't change
between STLport version 3 and 4, so the detection in config.hpp works
for either version.  If/When we reach a point that it can be
assumed/mandated to use STLport 4 (if using STLport at all, that is),
then we could go back to the what Beman had for detecting STLport.
AFAICT, we'd still need to include at least one header before doing
the detection, though.