The configure script should output something like:
checking native support for unordered_set... not working
checking TR1 unordered_set usability... ok
checking boost/unordered_set.hpp usability... yes
checking boost/unordered_set.hpp presence... yes
checking for boost/unordered_set.hpp... yes
checking ext/hash_set usability... yes
checking ext/hash_set presence... yes
checking for ext/hash_set... yes
As long as we have support for <unordered_set> either natively, or through TR1 or boost, we don't need <ext/hash_set> so it's safe to remove it. (see first five lines of output)
(<ext/hash_set> is only included directly in util/unordered-containers.h as a fallback after checking those configuration flags in order)
In fact, I don't think we even need to have <ext/hash_set> as a fallback for old compilers! Boost is already there to do that job.
The configure script should output something like:
checking native support for unordered_set... not working _set.hpp usability... yes _set.hpp presence... yes _set.hpp. .. yes
checking TR1 unordered_set usability... ok
checking boost/unordered
checking boost/unordered
checking for boost/unordered
checking ext/hash_set usability... yes
checking ext/hash_set presence... yes
checking for ext/hash_set... yes
As long as we have support for <unordered_set> either natively, or through TR1 or boost, we don't need <ext/hash_set> so it's safe to remove it. (see first five lines of output)
(<ext/hash_set> is only included directly in util/unordered- containers. h as a fallback after checking those configuration flags in order)
In fact, I don't think we even need to have <ext/hash_set> as a fallback for old compilers! Boost is already there to do that job.