[config] gcc and <unordered_set> vs <ext/hash_set>
Folks, Dave A. asked for a config macro to detect the presence of std conforming <unordered_set> and <unordered_map>. However, I've run into an unexpected issue: it appears that with gcc-4.3.x you cannot include both <unordered_set> and <ext/hash_set> as attempting to do so leads to endless errors inside the <ext/*> headers :-( Including either one of the headers is just fine though. So... how should we handled this? Not define BOOST_HAS_HASH when <unordered_set> *is* available? As far as I can tell the only library effected by this change would be Boost.Serialization which would lose has_set support in gcc's c++0x mode. How do folks feel about that? Regards, John.
Hi John ! On Tuesday 16 December 2008, John Maddock wrote:
Folks, Dave A. asked for a config macro to detect the presence of std conforming <unordered_set> and <unordered_map>.
This would be great.
However, I've run into an unexpected issue: it appears that with gcc-4.3.x you cannot include both <unordered_set> and <ext/hash_set> as attempting to do so leads to endless errors inside the <ext/*> headers :-(
Including either one of the headers is just fine though.
But the <unordered_*> headers are only available with -std=c++0x.
So... how should we handled this? Not define BOOST_HAS_HASH when <unordered_set> *is* available?
We don't use <hash_*> at the moment, so im +-0 with this idea.
As far as I can tell the only library effected by this change would be Boost.Serialization which would lose has_set support in gcc's c++0x mode. How do folks feel about that?
I remember that Dave was trying to eliminate the warnings from the BGL. <hash_set> is used in boost/graph/adjacency_list.hpp, too. I've disabled them for my project with BOOST_NO_HASH. I don't care about them, but there may be projects around using them. A short grep finds: ./boost/pending/container_traits.hpp:25:# include <hash_set> ./boost/pending/container_traits.hpp:30:# include <hash_map> ./boost/graph/adjacency_list.hpp:27:# include <hash_set> Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
on Tue Dec 16 2008, Juergen Hunold <juergen.hunold-AT-ivembh.de> wrote:
Hi John !
On Tuesday 16 December 2008, John Maddock wrote:
Folks, Dave A. asked for a config macro to detect the presence of std conforming <unordered_set> and <unordered_map>.
This would be great.
However, I've run into an unexpected issue: it appears that with gcc-4.3.x you cannot include both <unordered_set> and <ext/hash_set> as attempting to do so leads to endless errors inside the <ext/*> headers :-(
Including either one of the headers is just fine though.
But the <unordered_*> headers are only available with -std=c++0x.
Huh, good point. Too bad you have to set a compiler flag for that one.
As far as I can tell the only library effected by this change would be Boost.Serialization which would lose has_set support in gcc's c++0x mode. How do folks feel about that?
I remember that Dave was trying to eliminate the warnings from the BGL. <hash_set> is used in boost/graph/adjacency_list.hpp, too. I've disabled them for my project with BOOST_NO_HASH. I don't care about them, but there may be projects around using them.
A short grep finds: ./boost/pending/container_traits.hpp:25:# include <hash_set> ./boost/pending/container_traits.hpp:30:# include <hash_map> ./boost/graph/adjacency_list.hpp:27:# include <hash_set>
Yeah. Or maybe we should just use boost::unordered in future. It's hard to imagine that any of these projects have docs so specific about the container used that it would be a problem. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, Dec 16, 2008 at 9:48 PM, David Abrahams <dave@boostpro.com> wrote:
on Tue Dec 16 2008, Juergen Hunold <juergen.hunold-AT-ivembh.de> wrote:
Hi John !
On Tuesday 16 December 2008, John Maddock wrote:
Folks, Dave A. asked for a config macro to detect the presence of std conforming <unordered_set> and <unordered_map>.
This would be great.
However, I've run into an unexpected issue: it appears that with gcc-4.3.x you cannot include both <unordered_set> and <ext/hash_set> as attempting to do so leads to endless errors inside the <ext/*> headers :-(
Including either one of the headers is just fine though.
But the <unordered_*> headers are only available with -std=c++0x.
Huh, good point. Too bad you have to set a compiler flag for that one.
I think that they are also available with stdc++ TR1 implementation, which IIRC doesn't require to be enabled via compiler flags. HTH, -- gpd
John Maddock wrote:
Folks, Dave A. asked for a config macro to detect the presence of std conforming <unordered_set> and <unordered_map>.
However, I've run into an unexpected issue: it appears that with gcc-4.3.x you cannot include both <unordered_set> and <ext/hash_set> as attempting to do so leads to endless errors inside the <ext/*> headers :-( Including either one of the headers is just fine though.
So... how should we handled this? Not define BOOST_HAS_HASH when <unordered_set> *is* available?
That would make it impossible to read archives which contain hashed pointers under the current system. And of course one couldn't write portable programs which use the old hashed containers any more and not all compilers /libraries support ext/hash so the final result would be that one couldn't make a portable program with hashed containers.
As far as I can tell the only library effected by this change would be Boost.Serialization which would lose has_set support in gcc's c++0x mode. How do folks feel about that?
Seems to me the best would be not to include both headers in the same source module. That is, ignore the problem and just take the error message as a long winded version of "don't do this!!!!". Of course a short winded version would be better and maybe config can be ehanced to do that. Robert Ramey
Regards, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Tue Dec 16 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
John Maddock wrote:
Folks, Dave A. asked for a config macro to detect the presence of std conforming <unordered_set> and <unordered_map>.
However, I've run into an unexpected issue: it appears that with gcc-4.3.x you cannot include both <unordered_set> and <ext/hash_set> as attempting to do so leads to endless errors inside the <ext/*> headers :-( Including either one of the headers is just fine though.
So... how should we handled this? Not define BOOST_HAS_HASH when <unordered_set> *is* available?
That would make it impossible to read archives which contain hashed pointers under the current system.
Are you sure? I'd be a bit surprised if hash_set<T>'s serialized data couldn't be read into an unordered_set<T>. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Robert Ramey wrote:
So... how should we handled this? Not define BOOST_HAS_HASH when <unordered_set> *is* available?
That would make it impossible to read archives which contain hashed pointers under the current system. And of course one couldn't write portable programs which use the old hashed containers any more and not all compilers /libraries support ext/hash so the final result would be that one couldn't make a portable program with hashed containers.
??? Exactly, the old hashed containers aren't portable between compilers, will be removed in some future gcc release, and can't reliably be used in C++0x mode.
As far as I can tell the only library effected by this change would be Boost.Serialization which would lose has_set support in gcc's c++0x mode. How do folks feel about that?
Seems to me the best would be not to include both headers in the same source module. That is, ignore the problem and just take the error message as a long winded version of "don't do this!!!!". Of course a short winded version would be better and maybe config can be ehanced to do that.
OK, I've rigged the config system to allow both to be enabled at the same time for now. John.
participants (5)
-
David Abrahams -
Giovanni Piero Deretta -
John Maddock -
Juergen Hunold -
Robert Ramey