On Wed, Jul 31, 2013 at 7:41 PM, Joshua Cranmer 🐧 <pidgeo...@gmail.com>wrote:
> implementation, libc++, libstdc++, and stlport. Since most nice charts of > C++11 compatibility focus on what the compiler needs to do, I've put > together a high-level overview of the major additions to the standard > library [3]: > * std::function/std::bind -- Generalization of function pointers > Note that Eric Rescorla implemented his own std::bind polyfill when he was working on WebRTC. I also have some new code I am working on where std::bind is extremely helpful. > Now that you have the background for what is or will be in standard C++, > let me discuss the real question I want to discuss: how much of this should > we be using in Mozilla? > > For purposes of discussion, I think it's worth breaking down the C++ (and > C) standard library into the following components: > * Containers--vector, map, etc. > * Strings > * I/O > * Platform support (threading, networking, filesystems, locales) > * Other helpful utilities (std::random, std::tuple, etc.) > > The iostream library has some issues with using (particularly static > constructors IIRC), and is not so usable for most of the things that Gecko > needs to do. It is very useful for building a logging interface that is safer and more convenient than NSPR's printf-style logging. Note that, again, Eric Rescorla already built an (partial) iostream-based wrapper around NSPR for WebRTC. I would say that, if there is no additional overhead, then we should consider making iostream-based logging the default way of doing things in Gecko because it is so much less error-prone. > Even if fully using the standard library is untenable from a performance > perspective, usability may be enhanced if we align some of our APIs which > mimic STL functionality with the actual STL APIs. For example, we could add > begin()/end()/push_back()/etc. methods to nsTArray to make it a fairly > drop-in replacement for std::vector, or at least close enough to one that > it could be used in other STL APIs (like std::sort, std::find, etc.). > However, this does create massive incongruities in our API, since the > standard library prefers naming stuff with this_kind_of_convention whereas > most Mozilla style guides prefer ThisKindOfConvention. > Perhaps a more annoying issue--though not a showstoper--is that unique_ptr::release() means something quite different than nsXXXPtr::Release() means. > With all of that stated, the questions I want to pose to the community at > large are as follows: > 1. How much, and where, should we be using standard C++ library > functionality in Mozilla code? > We should definitely prefer using the standard C++ library over writing any new code for MFBT, *unless* there is consensus that the new thing we'd do in MFBT is substantially clearer. (For example, I think some people successfully argued that we should have our own atomic types because our interface is clearly better than std::atomic.) Even in the case where MFBT or XPCOM stuff is generally better, We should *allow* using the standard C++ library anywhere that has additional constraints that warrant a different tradeoff; e.g. needing to be built separately from Gecko and/or otherwise needing to minimize Gecko dependencies. > 3. How should we handle bridge support for standardized features not yet > universally-implemented? > Generally, I would much rather we implement std::whatever ourselves than implement mozilla::Whatever, all other things being equal. This saves us from the massive rewrites later to s/mozilla::Whatever/std::whatever/; while such rewrites are generally a net win, they are still disruptive enough to warrant trying to avoid them when possible. In the case where it is just STLPort being behind, we should just add the thing to STLPort (and try to upstream it). in the case where the lack of support for a useful standard library feature is more widespread, we should still implement std::whatever if the language support we have enables us to do so. I am not sure where such implementations should live. > 4. When should we prefer our own implementations to standard library > implementations? > It is a judgement call. The default should be to use standard library functions, but we shouldn't be shy about using our own stuff if it is clearly better. On the other side, we shouldn't be shy about replacing uses of same-thing-but-different Mozilla-specific libraries with uses of the standard libraries, all things being equal. > 5. To what degree should our platform-bridging libraries > (xpcom/mfbt/necko/nspr) use or align with the C++ standard library? > I am not sure why you include Necko in that list. Did you mean NSS? For NSPR and NSS, I would like to include some very basic utilities like ScopedPRFileDesc that are included directly in NSPR/NSS, so that we can use them in GTest-based tests, even if NSPR and NSS otherwise stick with C. But, I don't know if the module owners of those modules will accept them. > 6. Where support for an API we wish to use is not universal, what is the > preferred way to mock that support? > [Note: similar questions also apply to NSPR and NSS with respect to newer > C99 and C11 functionality.] > There is no tolerance for mass changes like s/PRInt32/int32_t/ in NSPR or NSS, AFAICT. C99 and C11 are basically off the table too, because Microsoft refuses to support them in MSVC. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
