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
>>>> 2. The <hash_map> header itself is not accessible as <hash_map>,
>>>> <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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk