On 12/10/2013 3:29 PM, Chris Pearce wrote:
It seems to me that we should be optimizing for developer productivity
first, and use profiling tools to find code that needs to be optimized.
For many of our developers, the STL is not an API that they are
intimately familiar with, so it's not altogether clear that using the
STL instead optimizes for developer productivity. Particularly since
moving between the STL API and Mozilla ADT API is painful due to present
differences, I don't think there is much benefit towards using STL
directly. It's also worth noting that large parts of the STL API are
horrendously misdesigned and have not been imitated by successor
languages--std::map, std::iterator are some good examples
here--reviewers have to be aware of the pitfalls of much of the STL, and
I doubt many of them are aware of them (I sure am not). As an example
here, when is std::vector::iterator invalidated by a mutation? What
about std::map::iterator? What about std::unordered_map::iterator?
(Hint: the answer is different for all three of them). And the number of
STL implementations we use that even attempt to provide a debug mode to
catch errors like this is 1, and it doesn't do a very thorough job of it.
Using the correct data structure from the start isn't premature
optimization: it's common sense, and we'd be killed by death of a
thousand papercuts if we don't follow that rule.
Also, some of the containers are not suitable for use in a codebase
that doesn't allow exceptions. For instance std::map.at() wouldn't be
appropriate in our code and may not compile.
We compile with -D_HAS_EXCEPTIONS=0 on Windows, so the use of
functions that throw should be caught at compile time, or at worst
cause backouts at landing. Won't that prevent us throwing exceptions?
I believe that in our current setup, code that attempts to throw an
exception will compile but instead abort at runtime.
AIUI, the current status of using the C++ standard containers is that
they aren't necessarily forbidden, but we should be careful about
checking our assumptions about how they use exceptions, how much they
cost in codesize, and whether we need to reimplement or subclass them
in MFBT in order to get better memory reporting.
Based on
https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code#C.2B.2B_and_Mozilla_standard_libraries
(thanks njn!) we can use std::unordered_map and std::unordered_set at
least. That still won't give us a convenient to use queue/deque through.
Do you not see the giant note at the top of that page saying "Don't
trust this information?" As the person who wrote 95% of that page, I can
tell you that the STL section does not contain any information about
what can and can't be used in Mozilla code, largely as a result of
trying to balance the need to explain what can be used in Mozilla versus
the desire to list the minimum features in C++11 code. This is
particularly true for the ADT section, as the executive decision has
been repeatedly affirmed to avoid STL containers as much as possible in
Mozilla code. Note, for example, that STLport (the version we have in
the tree) provides std::tr1::unordered_map, not std::unordered_map.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
