Re: [v3] deprecated ext/hash_map, ext/hash_set

["Jonathan Wakely" <jwakely dot gcc at gmail dot com>]

On 17/10/2007, Benjamin Kosnik <bkoz@redhat.com> wrote:
> This moves <ext/hash_map> and <ext/hash_set> into backwards.  Since
> the introduction of TR1's unordered containers, these old hash
> containers have been de facto deprecated: this just makes it official
> to those not paying attention.
>
> I'm hoping to align libstdc++ sources to reality, as the maintainers
> see it. In addition, I would like to time the addition of new
> interfaces (ie, C++0x) with the removal of deprecated interfaces.

Many users will be find it easier to move to GCC 4.(n+1) than they
will to modify all code using classes that the maintainers see as
ancient.

> To deprecate the SGI hash containers, one has to jump through a couple
> rounds of hoops. Here's an outline:
>
> 1) remove use of ext/hash_map, ext/hash_set in libstdc++ sources. Finished with:
> http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00687.html

Good stuff.  If nothing else that will help weed out any bugs or
performance problems with the new associative containers.

> 2) come up with equivalent debug mode functionality for unordered_map
> as compared to hash_map. Done with:
> http://gcc.gnu.org/ml/libstdc++/2007-10/msg00089.html

Excellent.  I've been thinking about this exact point over the past
few days.  I think the debug mode is one of the coolest things in
libstdc++ (thank you again, Doug) and would hate for the new library
components to be second-class citizens w.r.t debug mode.  How can
debug mode be leveraged for the other parts of TR1/C++0x?  Anything
the standard says is undefined is fair game for QOI improvements in
debug mode.

> 3) Remove pre-ISO C++ 1998 files from include/backward. We've been
> around and around on this, and I am not going to summarize past
> discussions here. Instead, I implement a modified proposal, whereby
> files not in Annex D (or otherwise in) ISO C++ 1998 are removed.
> Summarily.

Excellent.  As long as strstream and other Annex D headers stay then
I'm all for this.

> 4) Move ext/hash_map and friends into backward/hash_map, etc. Adjust docs, etc.

Will they then give deprecated warnings even in non-C++0x mode?
If so, does this mean people who want to use hash containers without
warnings  are effectively forced to use std::tr1 (which will probably
always be non-standard) or use the incomplete C++0x mode which does
even support auto or rvalue-refs, let alone concepts or threads?

Docs adjustment should include announcing TR1 support as more than
experimental. You can't ask users to move to experimental features in
preference to well-known containers that predate standard iostreams
and locales :)

> Whew.
>
> For my next couple tricks, I will be attempting to deprecate (in C++0x
> mode) auto_ptr, binder1st, and vector<bool>.

IMHO it would be a mistake to deprecate auto_ptr, even in C++0x mode,
until 1) there is a new ISO standard and 2) libstdc++ has unique_ptr.
I care less about the old binders and vector<bool> because they
weren't very usable in the first place, YMMV.  auto_ptr is flawed but
can still be put to good use.
Are you planning these changes for GCC 4.3?

Jon