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
>>> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk