C++ Logo


Advanced search

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

From: Edward Catmur <ecatmur_at_[hidden]>
Date: Wed, 21 Dec 2022 08:38:22 +0100
On Wed, 21 Dec 2022 at 08:29, Ville Voutilainen <ville.voutilainen_at_[hidden]>

> On Mon, 19 Dec 2022 at 14:51, S├ębastien Bini <sebastien.bini_at_[hidden]>
> wrote:
> >
> > On Mon, Dec 19, 2022 at 1:11 PM Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
> >>
> >> I don't get it. If we have a new kind of constructor, there is no ABI
> >> _break_, since it's just a new constructor. So why aren't you adding
> >> such
> >> a new constructor for pair?
> >>
> >> Since this is a semantic facility with semantic guarantees, using
> >> attributes here seems like the wrong thing to do.
> >
> >
> > I get your confusion. Let me explain in more detail. Let's say you want
> to call this relocation constructor with a function parameter as source
> object. This function parameter was passed by value to the function:
> >
> > void bar(T);
> > void foo(T val)
> > { bar(reloc val); }
> >
> > To simplify, the reloc call here will call the relocation constructor
> for us. When an object is passed to the relocation constructor, its
> destructor must not be called. So in the example, foo must not call the
> destructor of val. However, if foo's ABI is caller-destroy, then foo
> doesn't have the means of doing that, as it is not in charge of calling the
> destructor of val in the first place.
> The problem goes away if the semantics of destructive move are such
> that the destructive-moved-from object is in a state where
> destruction is valid but not necessary.

Yes; we don't want that, since then we would be unable to use relocate-only
types such as never-empty types such as not_null<unique_ptr>. For another
example, guard types often need to be relocatable, but move support and an
empty state add considerable complexity, often more than doubling the
amount of code required.

Received on 2022-12-21 07:38:34