End support for obsolete <ext/hash_set> header

[Alex Valavanis]

At the moment, we support builds using the ancient <ext/hash_set> header. As far as I understand it, this has been replaced by the <unordered_set> header in all modern C++ implementations (either in TR1, or in C++11).

Our support for hash mechanisms is pretty bloated and it'll help clean things up if we drop this ancient header.

Any objections if I remove it?

[su_v (suv-lp)]

How to figure out in advance whether that removal would affect r break local builds with a system compiler based on an older GCC version?

[Alex Valavanis (valavanisalex)]

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.

[Alex Valavanis (valavanisalex)]

Support removed in lp:inkscape r13231. This shouldn't cause any issues on any reasonably modern C++ std libraries and Boost provides a suitable fallback if it's really needed.