On Wed, Aug 7, 2013 at 6:47 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com>wrote:
> (Sorry for the late reply, please blame it on Canadian statutory holidays, > and my birthday date!) > Happy birthday! On Fri, Aug 2, 2013 at 11:09 PM, Brian Smith <br...@briansmith.org> wrote: > >> 1. It avoids a phase of mass rewrites s/mozilla:Whatever/std::whatever/. >> (See below). >> 2. It is reasonable to expect that std::whatever works as the C++ >> standard says it should. It isn't reasonable to expect mozilla::Whatever to >> work exactly like std::whatever. And, often, mozilla::Whatever isn't >> actually the same as std::whatever. >> > > As Jeff mentioned, I think it's more important that we expect developers > to read and believe the documentation where it exists. The MFBT code is > very well documented, and the documentation is usually in sync with the > implementation. That is already a huge improvement over the newer std::* > stuff. std::auto_ptr is perhaps the biggest example of people not reading > documentation about std::* stuff. ;-) > Still, all things being equal, it is better to help developers use std::* instead of inventing something new, because it is likely (and increasingly more likely) that they already know how std::* works. (I note that you also made this point below.) > But more importantly, as others mentioned, the fact that something lives > in the std namespace doesn't mean that it adheres to the C++ standard. So > it seems to me like you're assuming that code living in the std namespace > is bug free, but that's not true. And when something lives in the std > namespace, fixing it is very difficult. > I agree it is very difficult to deal with bugs in standard libraries. Finding a bug in the implementation of std::whatever in a compiler/stdlib we can't upgrade is a good reason to create mozilla::Whatever. Worrying, ahead of time, that std::whatever might maybe have a bug in some implementation, isn't a good reason to create mozilla::Whatever. YAGNI. > But for whatever it's worth, I think that in general, for the std > replacement code living in MFBT, it's best for us to try really hard to > match the C++ standard where it makes sense. We sometimes go through a > crazy amount of pain to do that (see my patch in bug 802806 as an > example!). But if something doesn't make sense in the C++ standard or is > not fit for our needs, we should do the right thing, depending on the case > at hand. > <snip> > But then again I don't find this argument very convincing in this > particular case. I hope that this discussion has provided some good > reasons why implementing out mozilla::Whatever sometimes makes sense. And > later on when we decide to switch to std::whatever, I'd consider such a > rewrite a net win because it makes our code easier to approach by people > familiar with std::whatever. > My argument is not that we should avoid creating mozilla::Whatever at all costs. My argument is that we should prefer upgrading compilers and/or just add/backport something to STLPort to writing new code in MFBT that is the same-but-different than what the standard C++ library provides. Obviously, if there is a major benefit to having our own thing, then we should do so. (I already gave the example of mozilla/Atomics.h.) > About the mozilla-build sed issue, that is really really > surprising/disappointing -- I'd have expected that we ship GNU sed there? > Even bsd sed on Mac supports -i. Please file a bug about this with more > details. > https://bugzilla.mozilla.org/show_bug.cgi?id=373784 (reported 2007-03-13). Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
