Date: Thu, 24 Apr 2025 10:55:51 +0300
On 24 Apr 2025 10:16, Jonathan Wakely via Std-Proposals wrote:
>
>
> On Thu, 24 Apr 2025, 02:09 Elazar via Std-Proposals, <std-
> proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
> Hey everyone,
>
> I've been working on a new proposal for the C++ Standard Library
> that I'd like to share: "A Library-Based Mechanism for Moved-From
> Initialization (moved_from())"
>
> *Problem:* Creating an object just to immediately overwrite it, like:
>
> BigExpensiveType obj; // Default construction we don't need
> obj = get_actual_value(); // Immediate overwrite
>
> This is especially wasteful for types with non-trivial constructors.
> Current workarounds like placement new or custom factory functions
> are either unsafe or non-standard.
>
>
> Use std::optional, that's safe and standard.
And also larger and heavier than necessary.
I often find std::optional a disappointment in practice. In objects with
lots of std::optional members, it nearly doubles the object size due to
padding, and I often find myself replacing it with separate T members
and bools or even std::bitset. This is, of course, tedious and requires
discipline on the user. It also needs T to be cheaply constructible, and
could benefit from a proposal like this one.
>
>
> On Thu, 24 Apr 2025, 02:09 Elazar via Std-Proposals, <std-
> proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
> Hey everyone,
>
> I've been working on a new proposal for the C++ Standard Library
> that I'd like to share: "A Library-Based Mechanism for Moved-From
> Initialization (moved_from())"
>
> *Problem:* Creating an object just to immediately overwrite it, like:
>
> BigExpensiveType obj; // Default construction we don't need
> obj = get_actual_value(); // Immediate overwrite
>
> This is especially wasteful for types with non-trivial constructors.
> Current workarounds like placement new or custom factory functions
> are either unsafe or non-standard.
>
>
> Use std::optional, that's safe and standard.
And also larger and heavier than necessary.
I often find std::optional a disappointment in practice. In objects with
lots of std::optional members, it nearly doubles the object size due to
padding, and I often find myself replacing it with separate T members
and bools or even std::bitset. This is, of course, tedious and requires
discipline on the user. It also needs T to be cheaply constructible, and
could benefit from a proposal like this one.
Received on 2025-04-24 07:55:54