Maybe resolve libstdc++/24537 (was: ...Re: Role of profile/hashtable.h?!?)

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi
> Let me think about it a bit.  I still see tons of code using hash_* in
> my benchmarks, so being able to test hash_* is important, at least to me.
> However, I'd also much prefer not to carry it around any longer.
>   
>From my point of view, a particular concern is libstdc++/24537: as you
can see in the audit trail, a neat way to fix it would be moving all the
legacy HP / SGI code from __gnu_cxx to __gnu_ext. I think that could
well be done, at this time, without creating any major problem to the
users, for ext/slist, ext/rope, ext/algorithm, ext/numeric and little
else... besides the hashed containers, which also live in __gnu_cxx. We
can maybe leave those alone for now...

Another reason of concern is for me, as I already said, is consistency:
we do not deliver debug-mode hash_* and that's very good, long term. I
think we really, really, don't want to encourage people using legacy,
essentially unsupported, stuff. Just the bare minimum the users want for
back compatibility. Looking forward we have *a lot* of work to do to
fully implement and maintain the C++0x conforming containers (as you may
have already noticed the last days...) in the various plain / debug /
profile forms...

Paolo.