Re: [boost] [Config] Re: serializing a hash_map (tweaks forgcc-3.3.4/libstdc++-v3)

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?

John.