On Fri, Nov 24, 2017 at 11:35 AM, Eric Rescorla <e...@rtfm.com> wrote: > On Thu, Nov 23, 2017 at 4:00 PM, smaug <sm...@welho.com> wrote: >> I guess I'd prefer UniquePtr::New() over MakeUnique to be more clear about >> the functionality. > > This seems like a reasonable argument in isolation, but I think it's more > important to mirror the standard C++ mechanisms and C++-14 already defines > std::make_unique. > > As a post-script, given that we now can use C++-14, can we globally replace > the MFBT clones of C++-14 mechanisms with the standard ones?
In general, no. std::unique_ptr is not a drop-in replacement for mozilla::UniquePtr, for instance, and people seem OK with that--plus maintaining our own smart pointer class opens up optimization opportunities the standard library can only implement with difficulty[0]. In a similar fashion, having our own mozilla::Move means we can implement checks on the use of Move that the standard library version can't. std::vector is not an adequate replacement for mozilla::Vector. And so forth. There are specific instances where using the standard library doesn't seem problematic: we have a bug open on replacing TypeTraits.h with type_traits, but that has run into issues with how we wrap STL headers, and nobody has devoted the time to figuring out how to deal with the issues. But each instance would have to be considered on the merits. -Nathan [0] See http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html and the ensuing discussion. There was discussion of standardizing this attribute, but it's not clear to me that std::unique_ptr could immediately take advantage of this without ABI breakage. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
