serializing a hash_map (tweaks for gcc-3.3.4/libstdc++-v3)
Had a couple problems serializing a hash map on gcc-3.3.4/gnu libstdc++-v3. Sorry if this is a repeat, I've googled around a bit and found nothing. Here are the tweaks necessary: 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... Cheers, -t
"troy d.straszheim" <troy@resophonic.com> writes:
Had a couple problems serializing a hash map on gcc-3.3.4/gnu libstdc++-v3. Sorry if this is a repeat, I've googled around a bit and found nothing. Here are the tweaks necessary:
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. Thanks! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Sep 12, 2004, at 2:55 PM, David Abrahams wrote:
"troy d.straszheim" <troy@resophonic.com> writes:
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... -t
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.
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
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.
Thanks, yes if you want to take this one on then that would be great. BTW, I've checked and we have two complete hash table implementations in the Boost files section (http://groups.yahoo.com/group/boost/files/), IMO it's a pity one of these hasn't been brought up for review, but I guess the most important thing is to sort out the wrapping of existing std lib implementations. John.
On Sun, Sep 12, 2004 at 04:27:08PM +0200, troy d.straszheim wrote:
On Sep 12, 2004, at 2:55 PM, David Abrahams wrote:
"troy d.straszheim" <troy@resophonic.com> writes:
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...
Yes the same changes apply to __GLIBCXX__ (i.e. GCC 3.4 onwards) Also, with GCC 3.0 the hash_map extension was in namespace std, not in ::__gnu_cxx. c.f. http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#5_4 jon -- Emacs is a nice OS - but it lacks a good text editor. That's why I am using Vim. - Anonymous
participants (4)
-
David Abrahams -
John Maddock -
Jonathan Wakely -
troy d.straszheim