On 8/2/2013 4:21 PM, Brian Smith wrote:
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.
The interface that the <iostream> library provides is really only
decently designed for outputting textual strings. For debugging
purposes, we do need a better C++ logging API; it could certainly reuse
the same idioms of <iostream>, but using it under the hood is a bad
idea. LLVM, for example, uses its own copy of std::ostream:
<http://llvm.org/doxygen/classllvm_1_1raw__ostream.html> (together with
errs() and outs() to send to stderr/stdout).
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.
I've started making an MDN page at
<https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code>
about what C++ features can/should be used. The basic recommendation I
think I want is to use the Mozilla-specific version, at least in "Gecko"
since it has slightly more features that we find viable (particularly
SizeOf*This functions). The problem is that, since I'm mostly either
work with comm-central or tree-wide mass conversions (and hence
MFBT/XPCOM), I don't know where the boundaries of "Gecko" should
rightfully lie.
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.
I include Necko because it is the core networking provider for the C++
side of the codebase. While it mostly uses NSPR under the hood for
everything, it is plausible that we could use code that bypasses NSPR
(this has, in effect, been suggested for DNS stuff in the past).
I was also referring to designing C++ APIs around proposed new features
that we can't use because they are insufficient (like std::thread).
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.
MSVC 2013 will actually have _Bool and designated initializers support
from C99. That they don't want to do mass conversion to bool/<stdint.h>
types, or presumably even losing the LL_* macros [every time I see one
of those, a part of me dies] is disappointing...
--
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
