Boost logo

Boost :

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.


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