Boost logo

Boost :

From: John Maddock (john_at_[hidden])
Date: 2004-09-13 09:32:02

>>> 1. BOOST_HAS_HASH is not defined for this stdlib, needs to be turned
>>> on.
>>> 2. The <hash_map> header itself is not accessible as <hash_map>, it's
>>> <ext/hash_map>, and
>>> 3. The BOOST_STD_EXTENSION_NAMESPACE in this case is "__gnu_cxx".
>>> I have a patched stdlibcpp3.hpp and serialization/hash_map.hpp if
>>> somebody wants 'em...
>> Yes, please post them as attachments, and put [Config] in your
>> subject line.
> Here they are. I figure there is a "best practice" I'm missing (that
> #ifdef __GLIBCPP__ looks out of place to me in hash_map) if so clue me
> in for future reference. Also that <ext/hash_map> might very well
> apply for __GLIBCXX__ as well, dunno, I made the minimum change to fix
> my platform...

We have a slight problem here - there are lots of slightly incompatible
versions of <hash_map> - turning on BOOST_HAS_HASH inside the config system
will break Boost code that relies on this signifying that a very particular
version of <hash_map> exists.

A while ago didn't someone submit a TR1 conforming hash table implementation
that defers to the std lib where possible? We probably ought to fix this
properly by creating <boost/hash_map.hpp> etc rather like we created
<boost/limits.hpp> to work around a similar problem.

Thoughts, and /or volunteers?


Boost list run by bdawes at, gregod at, cpdaniel at, john at