Re: [gcc 4.5 patch] Permit smaller hash tables for hash_map and hash_set

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

On Feb 24, 2009, at 9:29 AM, Ian Lance Taylor wrote:

> Paolo Carlini <paolo.carlini@oracle.com> writes:
>
> > > > I have a few patches to make them better in some circumstances.
> > > > These
> > > > ideas are incorporated in different from in the newer unordered_set
> > > > and unordered_map.  However, existing code still uses hash_map and
> > > > hash_set, so it may be useful to update them if we think that is  
> > > > OK.
> > >
> > > I believe there was a previous attempt to fix up this stuff. It was
> > > not
> > > well-received, although I don't especially remember the details. At
> > > this
> > > point, I think this kind of stuff should just be checked in.
> >
> > Well, probably I'm the one not receiving well that kind of change in
> > the past ;) Really, I'm still of the same opinion, that code should  
> > be
> > just frozen by now, we do *not* want to deal with regressions, at
> > least, certainly not me.
>
> Clearly we don't want to deal with regressions, but that is true of  
> all
> the libstdc++ code.  That is not in itself a reason to never change  
> the
> hash_map and hash_set code.

Well, it depends on the maintainer ;) For sure *I* do not want to do  
fix regression in such legacy code in ext/. Actually, if you ask me, I  
would have issued a deprecation notice for both hash_map and hash_set  
and then removed both at the first occasion, really, it's something  
obsoleted by the TR1 and C++0x standard facilities. Anyway, If  
Benjamin agrees to keep on maintaining those two containers vs  
regressions caused by new commits, then fine, just go ahead, of course.

Paolo.