[cfe-dev] [libc++] ext/hash function

[Chandler Carruth]

On Sun, Jul 31, 2011 at 11:12 AM, Chris Lattner <clattner at apple.com> wrote:

> On Jul 31, 2011, at 10:44 AM, Howard Hinnant wrote:
>
> > What I would like to discuss is:  how similar should they be made to the
> the __gnu_cxx hash containers?  The __gnu_cxx hash containers were
> purposefully not standardized without change because the committee saw
> defects in their behavior.  Should our "migration adaptors" go to extra
> effort to replicate such defects in the __gnu_cxx hash containers?
>
> My opinion is that they should emulate the SGI/GCC semantics as closely as
> possible.  These containers are not standard containers and thus their only
> purpose in life is to provide compatibility with non-standard code.  Trying
> to fix their design problems is highly counterproductive (IMO): code should
> move off of them, not suffer issues moving to libc++ because we tried to
> "improve" these already-known-broken containers.


This reflects my stance as well. In particular, changing interfaces of these
containers that can be reasonably expected to work in a predictable fashion
(such as the char* hash implementation, or the fact that the hash
implementation lives in the '__gnu_cxx' namespace, and can be explicitly
specialized within that namespace) make it easier to migrate to libc++ for
large codebases.

That said, some things weren't reasonably part of the interface of even
these legacy containers (such as iteration order details) and it doesn't
seem worth it to emulate them at great expense.


For reference, we've now done a trial migration of a reasonably large chunk
of our codebase to use libc++ and to see what breaks. We were bitten by both
the hash specializations and by the char* hash behavior, but not by
iteration order to my knowledge.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110731/24433461/attachment.html>