Hi,

With P2413 `std::unique_ptr<Base> base_ptr = std::make_unique<Derived>()` would become safer, it would fail to compile if Base didn't have a virtual destructor.

In the recent mailing list review making `std::unique_ptr<Base> base_ptr(new Derived());` safer also came up, but it's not proposed currently. I don't have a satisfactory solution to make the raw pointer constructors safer this way.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2413r0.html

Cheers,
Lénárd



From: Ville Voutilainen via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: August 24, 2021 12:38:51 AM GMT+01:00
To: sotrdg sotrdg via Std-Proposals <std-proposals@lists.isocpp.org>
Cc: Ville Voutilainen <ville.voutilainen@gmail.com>
Subject: Re: [std-proposals] Easier make_unique with deleter function

On Tue, 24 Aug 2021 at 02:22, Jason McKesson via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:

`make_unique` was not added because it was shorter to type. In a
pre-C++17 world, you couldn't guarantee that two argument expressions
in the same function call would not interleave with one another. As
such, `make_unique<T>(Args)` was a more exception-safe version of
`unique_ptr<T>(Args)`.

Of course, since C++17 fixed the problem at the language level (the
argument expressions can happen in any order, but the sub-expressions
cannot be interleaved), it has become unnecessary.

It has uses that some audiences consider more important than anything
else, such as being
able to avoid using new-expressions to create objects with unique ownership.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals