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

From: troy d.straszheim (troy_at_[hidden])
Date: 2004-09-13 13:32:21

On Sep 13, 2004, at 4:32 PM, John Maddock wrote:

>>>> 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.

I was about to send out those tweaks for hash_set, I guess I'll hold 
off.  Far as I can tell the actual use of a hash is restricted to 
graph/adjacency_list...   Also I saw the mail from Jonathan Wakely 
about the namespace in 3.0 and __GLIBCXX__ in 3.4, so those patches are 
incomplete at best (and they do break that graph module).  I'll 
volunteer to have a go at it this, if you like, and if you care to 
clarify a bit what the issues are.  It would be nice to have this hash 
in one place.

-t