C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Relocation in C++

From: Maciej Cencora <m.cencora_at_[hidden]>
Date: Wed, 2 Mar 2022 12:15:08 +0100
You may assume whatever you want, but behaviour of your program may
change depending on consume impl (because managed resource will be
destroyed at different times).
And without language level move/relocate, the only way to workaround
this problem is to x = {}, after the consume call - but that requires
default constructiblity which may not be possible/may be costly.

Regards,
Maciej

śr., 2 mar 2022 o 12:08 Ville Voutilainen
<ville.voutilainen_at_[hidden]> napisał(a):
>
> On Wed, 2 Mar 2022 at 12:56, Maciej Cencora via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> > What is even worse, given following code:
> > void consume(X&&);
> > void bar()
> > {
> > X x;
> > consume(std::move(x));
> > ...
> > }
> >
> > after the consume call, you have no idea whether x was actually
> > consumed by invoking move-constructor/move assignment operator or not,
> > without looking at the implementation of consume func.
>
> So what? I will just assume that it consumed x, and program
> accordingly. I don't need to know that
> it perhaps didn't.
>
> >
> > The only way to solve this, is to introduce actual move/relocation as
> > language level construct (via e.g. proposed relocate operator), i.e.:
> > void consume(X x);
> > void bar()
> > {
> > X x;
> > consume(relocate x);
> > ...
> > }
> > Now after the consume call, x is no longer 'accessible' for further
> > code, and the user can be sure that the consume function really
> > 'consumed' it.
>
> I'm sure there are valid and reasonable uses (performance) for
> relocation, but this doesn't seem to be one of them.

Received on 2022-03-02 11:15:21