Boost logo

Boost :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-01-26 19:05:26


Jonathan Turkanis wrote:
>"Reece Dunn" <msclrhd_at_[hidden]> wrote in message:
> > >If Dinkumware has made this change uniformly in its various
> > >distributions, it sounds like BOOST_STD_EXTENSION_NAMESPACE should
>be
> > >defined to be stdext in boost/config/stdlib/dinkumware.hpp if
> > >_CPPLIB_VER is a certain value or higher (313?).
> >
> > I have done a little digging:
> >
> >
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcstdlib/html/vclrfhashmap_class.asp
> > says:
> >
> > "In Visual C++ .NET 2003, members of the <hash_map> and
> > <hash_set> header files are no longer in the std namespace,
> > but rather have been moved into the stdext namespace."
> >
> > Also, the online Dinkumware reference
> > (http://www.dinkumware.com/manuals/reader.aspx?b=p/&h=hash_map.html)
>places
> > hash_xxx in the std namespace. Therefore, it is specific to VC7.1
>(unless
> > Intel has done something similar?).
>
>That's interesting. Since the compiler is determined before the
>standard library, it would still be possible to put the definition in
>boost/config/stdlib/dinkumware.hpp, like so
>
> #if defined(BOOST_MSVC) && (BOOST_MSVC >= 1310)
> #define BOOST_STD_EXTENSION_NAMESPACE stdext
> #endif
>
>Maybe one should check _CPPLIB_VER for good measure. This sounds
>reasonable. What do you think?

I agree. The question is, should the test be BOOST_MSVC >= 1310 or
BOOST_MSVC == 1310, likewise for the _CPPLIB_VER test. I say this because a
future version of VC may move hash_xxx back into the std namespace for
future standard library conformance (does TC1 have hash_map, etc.?).

My instinct would be to leave it as BOOST_MSVC >= 1310 for now, then add
BOOST_MSVC <= xxx when necessary. (This will however lead to a long
condition expression!)

Regards,
Reece

_________________________________________________________________
Use MSN Messenger to send music and pics to your friends
http://www.msn.co.uk/messenger


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk