Re: Can we start using C++ STL containers in Mozilla code?
在 2013年12月10日星期二 UTC+8下午5:28:21，Chris Pearce写道： 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. Title: The core of the core of the big data solutions -- Map Author: pengwenwei Email: Language:c++ Platform:Windows, linux Technology: Perfect hash algorithm Level: Advanced Description: Map algorithm with high performance Section MFC c++ map stl SubSection c++ algorithm License: (GPLv3) Download demo project - 1070 Kb Download source - 1070 Kb Introduction: For the c++ program, map is used everywhere.And bottleneck of program performance is often the performance of map.Especially in the case of large data,and the business association closely and unable to realize the data distribution and parallel processing condition.So the performance of map becomes the key technology. In the work experience with telecommunications industry and the information security industry, I was dealing with the big bottom data,especially the most complex information security industry data,all can’t do without map. For example, IP table, MAC table, telephone number list, domain name resolution table, ID number table query, the Trojan horse virus characteristic code of cloud killing etc.. The map of STL library using binary chop, its has the worst performance.Google Hash map has the optimal performance and memory at present, but it has repeated collision probability.Now the big data rarely use a collision probability map,especially relating to fees, can’t be wrong. Now I put my algorithms out here,there are three kinds of map,after the build is Hash map.We can test the comparison,my algorithm has the zero probability of collision,but its performance is also better than the hash algorithm, even its ordinary performance has no much difference with Google. My algorithm is perfect hash algorithm,its key index and the principle of compression algorithm is out of the ordinary,the most important is a completely different structure,so the key index compression is fundamentally different.The most direct benefit for program is that for the original map need ten servers for solutions but now I only need one server. Declare: the code can not be used for commercial purposes, if for commercial applications,you can contact me with QQ 75293192. Download: https://sourceforge.net/projects/pwwhashmap/files Applications: First,modern warfare can’t be without the mass of information query, if the query of enemy target information slows down a second, it could lead to the delaying fighter, leading to failure of the entire war. Information retrieval is inseparable from the map, if military products use pwwhashMap instead of the traditional map,you must be the winner. Scond,the performance of the router determines the surfing speed, just replace open source router code map for pwwHashMap, its speed can increase ten times. There are many tables to query and set in the router DHCP ptotocol,such as IP,Mac ,and all these are completed by map.But until now,all map are using STL liabrary,its performance is very low,and using the Hash map has error probability,so it can only use multi router packet dispersion treatment.If using pwwHashMap, you can save at least ten sets of equipment. Third,Hadoop is recognized as the big data solutions at present,and its most fundamental thing is super heavy use of the map,instead of SQL and table.Hadoop assumes the huge amounts of data so that the data is completely unable to move, people must carry on the data analysis in the local.But as long as the open source Hadoop code of the map changes into pwwHashMap, the performance will increase hundredfold without any problems. Background to this article that may be useful such as an introduction to the basic ideas presented: http://blog.csdn.net/chixinmuzi/article/details/1727195 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
On 12/10/2013 16:17, Joshua Cranmer wrote: I think the right answer is to make the myriad of datatypes we have more STL-ish--as a first step at least, can we at least add iterator support for them and get rid of the abominable EnumerateForwards/EnumerateBackewards methods? This would allow us to use range-based for once our minimum compiler support gets there. Yes please. From what i saw so far we even have a bunch different iteration approaches with the current Mozilla containers. We also seem to have a lot of algorithmic duplication which seems pretty bad for maintenance etc. - getting all, or most, containers to implement compatible interfaces would allow for future improvements and cleanups. Georg ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Can we start using C++ STL containers in Mozilla code?
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
Note that we already do use at least those STL containers for which we don't have an equivalent in the tree. I've seen usage of at least: std::map, std::set, and std::bitset. I think that Nick has a good point about reporting memory usage, but I think that the right solution to this problem is to add Mozilla equivalents for the STL data structures that we need to fork, not to skew all your design to use the data structures that we have instead of the ones you need. Forking STL data structures into Mozilla code seems reasonable to me. Besides memory reporting, it also gives us another benefit: guarantee of consistent implementation across platforms and compilers. Benoit 2013/12/10 Nicholas Nethercote n.netherc...@gmail.com On Tue, Dec 10, 2013 at 8:28 PM, Chris Pearce cpea...@mozilla.com wrote: Hi All, Can we start using C++ STL containers like std::set, std::map, std::queue in Mozilla code please? https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code#C.2B.2B_and_Mozilla_standard_libraries has the details. As a general rule of thumb, prefer the use of MFBT or XPCOM APIs to standard C++ APIs. Some of our APIs include extra methods not found in the standard API (such as those reporting the size of data structures). I'm particularly attuned to that last point. Not all structures grow large enough to be worth reporting, but many are. In the past I've converted STL containers to Mozilla containers just to get memory reporting. Nick ___ 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
Re: Can we start using C++ STL containers in Mozilla code?
Also note that IIUC, the only thing that prevents us from solving the memory-reporting problem using a STL allocator, is that the spec doesn't allow us to rely on storing per-object member data on a STL allocator. Even without that, we could at least have a STL allocator doing per-STL-container-class memory reporting, so that we can at least know how much memory is taken by all std::set 's together. Just so we know if that ever becomes a significant portion of dark matter. Benoit 2013/12/10 Benoit Jacob jacob.benoi...@gmail.com Note that we already do use at least those STL containers for which we don't have an equivalent in the tree. I've seen usage of at least: std::map, std::set, and std::bitset. I think that Nick has a good point about reporting memory usage, but I think that the right solution to this problem is to add Mozilla equivalents for the STL data structures that we need to fork, not to skew all your design to use the data structures that we have instead of the ones you need. Forking STL data structures into Mozilla code seems reasonable to me. Besides memory reporting, it also gives us another benefit: guarantee of consistent implementation across platforms and compilers. Benoit 2013/12/10 Nicholas Nethercote n.netherc...@gmail.com On Tue, Dec 10, 2013 at 8:28 PM, Chris Pearce cpea...@mozilla.com wrote: Hi All, Can we start using C++ STL containers like std::set, std::map, std::queue in Mozilla code please? https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code#C.2B.2B_and_Mozilla_standard_libraries has the details. As a general rule of thumb, prefer the use of MFBT or XPCOM APIs to standard C++ APIs. Some of our APIs include extra methods not found in the standard API (such as those reporting the size of data structures). I'm particularly attuned to that last point. Not all structures grow large enough to be worth reporting, but many are. In the past I've converted STL containers to Mozilla containers just to get memory reporting. Nick ___ 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
Re: Can we start using C++ STL containers in Mozilla code?
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). -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
On 12/10/13 9:49 AM, Benoit Jacob wrote: since AFAIK we don't have a HashSet class in mfbt or xpcom. It's called nsBaseHashtable. Granted, using it as a hashset is not that intuitive. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
On Tue, Dec 10, 2013 at 1:28 AM, Chris Pearce cpea...@mozilla.com 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform One thing I haven't seen mentioned yet are the codesize consequences of using STL containers. Last time I saw numbers the STL containers generated significantly more code than their XPCOM equivalents. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
On 12/10/13 9:09 AM, Boris Zbarsky wrote: On 12/10/13 9:49 AM, Benoit Jacob wrote: since AFAIK we don't have a HashSet class in mfbt or xpcom. It's called nsBaseHashtable. Granted, using it as a hashset is not that intuitive. There's also js::HashSet in js/public/HashTable.h. -j ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
On 12/10/2013 3: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. The sizeOfExcludingThis/sizeOfIncludingThis methods on our containers are one feature not found in STL. There are some codesize concerns in using STL, as it is much more template-heavy than our own implementations (particularly in regards to std::unordered_map/nsTHashtable). The final issue is that performance characteristics may be very different: C++11 disallows copy-on-write semantics for std::string, for example; in another edge case, most STL containers' move constructors require noexcept semantics to become enabled (and autodegrades move to copy in most cases), and I'm not certain that compiling without exception support would grant us those semantics. Also, std::set and std::map are the wrong containers to use 95% of the time. If people don't want to use nsTHashtable because the API sucks, it's better to change the API for nsTHashtable rather than use the wrong datatype. I think the right answer is to make the myriad of datatypes we have more STL-ish--as a first step at least, can we at least add iterator support for them and get rid of the abominable EnumerateForwards/EnumerateBackewards methods? This would allow us to use range-based for once our minimum compiler support gets there. -- 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
Re: Can we start using C++ STL containers in Mozilla code?
On 12/10/2013 9:49 AM, Benoit Jacob wrote: 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. nsTHashtableKeyType is the XPCOM hashset. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
On 12/10/2013 4: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. njn already mentioned the memory-reporting issue. 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. 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. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
On 12/10/2013 09:49 AM, Benoit Jacob wrote: 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. I posit that if there is a map/set where the number of entries causes this to be a concern, we should not be using types where we can't report the memory usage. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
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
Re: Can we start using C++ STL containers in Mozilla code?
On Wed, Dec 11, 2013 at 10:29 AM, Chris Pearce cpea...@mozilla.com 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. 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. Keep in mind that proliferation of different types for the same functionality hurts developer productivity in various ways, especially when they have quite different APIs. That's the main reason I'm not excited about widespread usage of a lot of new (to us) container types. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
2013/12/10 Chris Pearce cpea...@mozilla.com 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. I agree with the above. I would also like to underline an advantage of the STL's design: the API is very consistent across containers, which allows to most easily switch containers (e.g. switch between map and unordered_map) and recompile. This has sometimes been derided as a footgun as one can unintentionally use a container with an algorithm that isn't efficient with it. But this also has a really nice, important effect: that one can avoid worrying too early about optimization details, such as whether a binary tree is efficient enough for a given use case or whether a hash table is needed instead. By contrast, our current Mozilla containers have each their own API and no equivalent of the STL's iterators, so code using one container becomes married to it. I believe that this circumstance is why optimization details have been brought up IMHO prematurely in this thread, needlessly complicating this conversation. 2013/12/10 Robert O'Callahan rob...@ocallahan.org Keep in mind that proliferation of different types for the same functionality hurts developer productivity in various ways, especially when they have quite different APIs. That's the main reason I'm not excited about widespread usage of a lot of new (to us) container types. For the same reason as described above, I believe that adopting STL containers is the solution, not the problem! The STL shows how to design containers that have a sufficiently similar API that, in most cases where that makes sense (e.g. between a map and an unordered_map), you can switch containers without having to adapt to a different API. Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
Also note that IIUC, the only thing that prevents us from solving the memory-reporting problem using a STL allocator, is that the spec doesn't allow us to rely on storing per-object member data on a STL allocator. I believe C++11 supports this. Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
On Tue, Dec 10, 2013 at 09:17:22AM -0600, Joshua Cranmer ? wrote: On 12/10/2013 3: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. The sizeOfExcludingThis/sizeOfIncludingThis methods on our containers are one feature not found in STL. There are some codesize concerns in using STL, as it is much more template-heavy than our own implementations (particularly in regards to std::unordered_map/nsTHashtable). The final issue is that performance characteristics may be very different: C++11 disallows copy-on-write semantics for std::string, for example; in another edge case, most STL containers' move constructors require noexcept semantics to become enabled (and autodegrades move to copy in most cases), and I'm not certain that compiling without exception support would grant us those semantics. Also, std::set and std::map are the wrong containers to use 95% of the time. If people don't want to use nsTHashtable because the API sucks, it's better to change the API for nsTHashtable rather than use the wrong datatype. I think the right answer is to make the myriad of datatypes we have more STL-ish--as a first step at least, can we at least add iterator support for them and get rid of the abominable EnumerateForwards/EnumerateBackewards methods? This would allow us to use range-based for once our minimum compiler support gets there. +1 Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
On Wed, Dec 11, 2013 at 10:50 AM, Benoit Jacob jacob.benoi...@gmail.comwrote: 2013/12/10 Robert O'Callahan rob...@ocallahan.org Keep in mind that proliferation of different types for the same functionality hurts developer productivity in various ways, especially when they have quite different APIs. That's the main reason I'm not excited about widespread usage of a lot of new (to us) container types. For the same reason as described above, I believe that adopting STL containers is the solution, not the problem! The STL shows how to design containers that have a sufficiently similar API that, in most cases where that makes sense (e.g. between a map and an unordered_map), you can switch containers without having to adapt to a different API. I'm not a fan of the STL's approach of making every data structure feel like an array. It leads to nonsense like the erase-remove idiom. A remove function that doesn't actually remove anything, now that's a footgun :-). Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
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
Re: Can we start using C++ STL containers in Mozilla code?
Erase-remove seems like poor naming, more than anything. I think that iterators (pretending things are arrays) are generally really handy. Alternatives (needing to do everything with pfns) really tend towards arcaneness and are often awkward to use. In my experience, docs for 'our' containers are also miles behind what the STL has available. We don't *always* need to use the maximally efficient container type. Let profiling and knowledge of use-cases show us when we need fast containers. Most of the time, I just want simple containers. (particularly for DEBUG-only code) -Jeff - Original Message - From: Robert O'Callahan rob...@ocallahan.org To: Benoit Jacob jacob.benoi...@gmail.com Cc: Chris Pearce cpea...@mozilla.com, dev-platform dev-platform@lists.mozilla.org Sent: Tuesday, December 10, 2013 2:04:06 PM Subject: Re: Can we start using C++ STL containers in Mozilla code? On Wed, Dec 11, 2013 at 10:50 AM, Benoit Jacob jacob.benoi...@gmail.comwrote: 2013/12/10 Robert O'Callahan rob...@ocallahan.org Keep in mind that proliferation of different types for the same functionality hurts developer productivity in various ways, especially when they have quite different APIs. That's the main reason I'm not excited about widespread usage of a lot of new (to us) container types. For the same reason as described above, I believe that adopting STL containers is the solution, not the problem! The STL shows how to design containers that have a sufficiently similar API that, in most cases where that makes sense (e.g. between a map and an unordered_map), you can switch containers without having to adapt to a different API. I'm not a fan of the STL's approach of making every data structure feel like an array. It leads to nonsense like the erase-remove idiom. A remove function that doesn't actually remove anything, now that's a footgun :-). Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ 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
Re: Can we start using C++ STL containers in Mozilla code?
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. Developers come and go, however, and the average C++ developer is more likely to be familiar with STL interfaces than with Mozilla ADT interfaces. 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-- Templates are a feature of C++ that have not been imitated by successor languages (no, generics do not count), and yet they are one of the most powerful features of C++. I view the STL's iterator model in a similar way. 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). While the answers are different for all of them, they (1) follow logically from how the data structures are expected to be implemented and (2) are well-documented. Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we start using C++ STL containers in Mozilla code?
[I'm highlighting this exchange, because it's been buried somewhat; apologies for the misleading information] On Tue, Dec 10, 2013 at 4:29 PM, Joshua Cranmer pidgeo...@gmail.com wrote: 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
