> 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
I can't access that bug, but maybe you mean https://bugzilla.mozilla.org/show_bug.cgi?id=onelogger ? I feel like the goals there are orthogonal to NSPR vs iostream. I haven't had a chance to work on this lately, but I do intend to land something when I can. On Fri, Aug 2, 2013 at 2:41 PM, Ethan Hugg <ethanh...@gmail.com> wrote: >>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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
