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

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. hashmap 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