On Thu, Nov 23, 2017 at 4:00 PM, smaug <sm...@welho.com> wrote: > On 11/23/2017 11:54 PM, Botond Ballo wrote: > >> I think it makes sense to hide a 'new' call in a Make* function when >> you're writing an abstraction that handles allocation *and* >> deallocation. >> >> So MakeUnique makes sense, because UniquePtr takes ownership of the >> allocated object, and will deallocate it in the destructor. MakeRefPtr >> would make sense for the same reason. >> > I almost agree with this, but, all these Make* variants hide the > information that they are allocating, > and since allocation is slow, it is usually better to know when allocation > happens. > 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? -Ekr > > > -Olli > > > >> But in cases where a library facility is not taking ownership of the >> object, and thus the user will need to write an explicit 'delete', it >> makes sense to require that the user also write an explicit 'new', for >> symmetry. >> >> NotNull is a bit of a weird case because it can wrap either a raw >> pointer or a smart pointer, so it doesn't clearly fit into either >> category. Perhaps it would make sense for MakeNotNull to only be >> usable with smart pointers? >> >> Cheers, >> Botond >> >> > _______________________________________________ > 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
