[llvm-dev] [libcxx-dev] Removing deprecated <ext/hash_set>, <ext/hash_map> and <ext/__hash>

Marshall Clow via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 6 10:23:04 PST 2019


On Wed, Feb 6, 2019 at 9:36 AM Louis Dionne via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:

> On Feb 5, 2019, at 23:18, Chandler Carruth <chandlerc at gmail.com> wrote:
>
> FWIW, I'm pretty sure we still have plenty of code using them. We've not
> done any analysis to see what timeframe that code could be be updated on --
> our focus has been on *adopting* libc++ (and easing that path), not
> removing the uses of weird things that it also supports. I'll point out
> that I'd rather focus our energy on adopting libc++ than even doing this
> analysis. ;]
>
> I somewhat agree with Joerg that it would be good to understand the
> motivation. Much like a bunch of our other compatibility things (GCC flags,
> language extensions, etc.), having these headers helps encourage / ease
> adoption which seems a generally good thing for libc++. I can imagine that
> there is some large cost to keeping these around that would motivate
> removing them, but I don't see anything about that in the above?
>
>
> To be clear: there is not a large cost in keeping those headers around. I
> don't think that's the question, since the same could be said of almost any
> removal of deprecated API. The cost of keeping code around is usually not
> that large if you decide not to maintain it anymore. But that's called code
> rot, and it's generally not a good idea to accumulate too much of it.
> hash_map probably has bugs that we haven't and won't fix, etc.
>

FWIW -- My response (for several years) to any reported problems in
`__gnu_cxx::hash_map/set` has been "use the ones in std::, then"

-- Marshall

P.S. The implementation in __gnu_cxx is NOT a faithful implementation of
what libstdc++ has; it is a wrapper over std::unordered_map/set.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190206/43fa353e/attachment.html>


More information about the llvm-dev mailing list