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.
i.e. we should be able to use STL containers where we need basic ADTs in
day-to-day coding, and if instances of these containers show up in
profiles then we should look at moving indivdual instances over to more
optimized data structures.
On 12/11/2013 4:42 AM, Benjamin Smedberg wrote:
njn already mentioned the memory-reporting issue.
We already have this problem with third party libraries that we use. We
should work towards having a port of the STL that uses our memory
reporters, so that we can solve this everywhere, and influence the size
of generated code for these templates.
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?
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.
Chris P.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
