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



-------- Original Message --------
From: Ville Voutilainen via Std-Proposals <std-proposals_at_[hidden]>
Sent: August 24, 2021 12:38:51 AM GMT+01:00
To: sotrdg sotrdg via Std-Proposals <std-proposals_at_[hidden]>
Cc: Ville Voutilainen <ville.voutilainen_at_[hidden]>
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_at_[hidden]> 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_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals