C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Idea: moved_from<T>() for Efficient Moved-From State Construction

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Thu, 24 Apr 2025 09:17:31 +0100
On Thu, 24 Apr 2025, 08:32 Andrey Semashev via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On 24 Apr 2025 04:14, Jason McKesson via Std-Proposals wrote:
> >
> > Many `std::list` implementations need to have an allocated node to
> > function. So the default constructor creates one. But the move
> > constructor *also* allocates one for the moved-from object, since
> > moved-from objects have to still be valid (this is also why
> > `std::list`'s move constructor is not required to be noexcept). So
> > it's unclear when exactly this would be advantageous.
>
> A moved-from object only needs to be destructible and assignable-to.


Citation needed.


It
> doesn't need to be valid for any other operations. In your std::list
> example, the move assignment/constructor can leave the moved-from object
> without the node, if the std::list's destructor and assignment support
> that state.
>

No, a moved-from std::list also needs to support all operations that have
no preconditions, such as size() and empty() and begin() and end().


I really wish the "moved-from state only needs to support assignment and
destruction" meme would die. You can use that convention for your own types
of your want, but please don't tell people it's a general rule. It's not.

Received on 2025-04-24 08:17:48