2013/12/10 smaug <sm...@welho.com> > On 12/10/2013 11:28 AM, Chris Pearce wrote: > >> Hi All, >> >> Can we start using C++ STL containers like std::set, std::map, std::queue >> in Mozilla code please? Many of the STL containers are more convenient to >> use than our equivalents, and more familiar to new contributors. >> >> I understand that we used to have a policy of not using STL in mozilla >> code since some older compilers we wanted to support didn't have very good >> support, but I'd assume that that argument no longer holds since already >> build and ship a bunch of third party code that uses std containers (angle, >> webrtc, chromium IPC, crashreporter), and the sky hasn't fallen. >> >> I'm not proposing a mass rewrite converting nsTArray to std::vector, just >> that we allow STL in new code. >> >> Are there valid reasons why should we not allow C++ STL containers in >> Mozilla code? >> >> Cheers, >> Chris P. >> > > > std::map/set may not have the performance characteristics people think. > They are significantly slower than > xpcom hashtables (since they are usually trees), yet people tend to use > them as HashTables or HashSets. > > Someone should compare the performance of std::unordered_map to our > hashtables. > (Problem is that the comparison needs to be done on all the platforms). >
There are many non-performance-sensitive use cases where std::set or std::map does what we need, and it has a better API than pldhash or our wrappers around it. Often, it makes for easier-to-read code, especially std::set compared to using a hashtable to do the same thing, since AFAIK we don't have a HashSet class in mfbt or xpcom. std::map and std::set are also free of any size restriction, and do not require a contiguous part of our address space (see https://bugzilla.mozilla.org/show_bug.cgi?id=944810#c12 ) , so they won't run OOM before we are actually OOM. They can even have performance advantages in some cases. Their worst-case complexity is actually lot better than a pldhash as they never require a big realloc, and IIUC they should typically have less overhead than hashtables for small numbers of elements. Also, I'm not aware of any mozilla equivalent of std::bitset. Just mentioning a few reasons why people may want to use STL containers. Benoit > > > > -Olli > > > > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
