[libcxx] r260012 - Cleanup node-type handling in the unordered containers

Eric Fiselier via cfe-commits cfe-commits at lists.llvm.org
Wed Feb 17 21:33:23 PST 2016


> How big a maintenance burden is it?  Is there a way to reduce the burden?

It's actually not *that* big of a maintenance burden because it's mostly
just a shallow wrapper around <__hash_table>.

What's been frustrating me is that there were *NO TESTS*. So modifying
<__hash_table> is a stab in the dark. I checked in a "breathing" tests
in r261181. Hopefully
that will help a bit.

/Eric

On Mon, Feb 15, 2016 at 5:26 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

>
> > On 2016-Feb-10, at 19:10, Marshall Clow <mclow.lists at gmail.com> wrote:
> >
> > On Wed, Feb 10, 2016 at 2:46 PM, Duncan P. N. Exon Smith via cfe-commits
> <cfe-commits at lists.llvm.org> wrote:
> > I'm hoping only a year or two (or three...)?
> >
> > As I pointed out to Eric on IRC, those files have had a "deprecation
> warning" every time they are included ... since 2010.
>
> Yes, anyone that has already transitioned to libc++ has no excuse.  They
> should just stop using ext/hash_map.
>
> Unfortunately we also ship this:
>
> http://www.opensource.apple.com/source/libstdcxx/libstdcxx-104.1/include/c++/4.2.1/ext/hash_map
>
> ^ It doesn't have any such #warning.  Keeping ext/hash_map around makes it
> easier to transition people over to libc++.
>
> How big a maintenance burden is it?  Is there a way to reduce the burden?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160217/fa4058a1/attachment.html>


More information about the cfe-commits mailing list