I wrote: > > The thread arguing about this has gone on for a while, so I think > > it's time to gather some data to answer the question of just how bad > > it will be if we accept the decision to move ext/hash_set and ext_hash_map > > into a different directory and to deprecate them. > > > > Any of you out there who put out distros or port collections: how many > > packages in your distro use these classes? You can grep for > > > > '# *include *<ext/hash' > > > > I'm particularly interested in the "Debian number", since the package > > collection is so large. Other information about use of these classes > > will be interesting as well.
On Thu, Oct 25, 2007 at 09:52:52PM -0700, Ian Lance Taylor wrote: > Here is something to look at: > > http://google.com/codesearch?q=%23include+%3Cext%2Fhash&btnG=Search&hl=en&lr= Thanks, Ian (and thanks, Google). There are about 400 hits, though I have no idea how complete the Google codebase is compared to what's in a distro. Thinks that will need fixing include inkscape, Boost, wxWindows, and kdevelop, and at least 50 other programs, though it's hard to get a good count, since the search is by file rather than by program. I do see that monotone can use either the TR1 unordered containers or <ext/hash_{map,set}>, but that's the only one I saw. Lots of programs are designed to look either for <hash_set> or for <ext/hash_set>, but they won't look for <backward/hash_set>. It also appears that some programs are designed to fall back to <set> or <map> (therefore paying a performance penalty) if the configure script does not find <hash_set> or <ext/hash_set>. Some programs try to isolate the details of where the headers are by having one header with #ifdefs that, in turn, does the #include of <ext/hash_{set,map}>, but many others do not.
