>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.
I found this comment interesting. It wasn't that long ago I was instructed to get rid of all iostream-based logging from media/webrtc/signaling and media/mtransport if it we wanted the logging to appear in opt builds. https://bugzilla.mozilla.org/show_bug.cgi?id=795126 https://bugzilla.mozilla.org/show_bug.cgi?id=841899 I agree that iostream-based logging would be safer. If we had it I wouldn't have had to work on this one: https://bugzilla.mozilla.org/show_bug.cgi?id=855335 Can we now use iostreams throughout this code? -EH On Fri, Aug 2, 2013 at 2:21 PM, Brian Smith <br...@briansmith.org> wrote: > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
