Date: Mon, 2 May 2022 14:59:24 +0100
On Mon, 2 May 2022 at 14:39, Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On 02/05/2022 15:27, Edward Catmur via Std-Proposals wrote:
> > Do you have examples of such classes?
> >
> >
> > From my perspective, and this is predicated on relocation ending
> > lifetime such that the destructor is not called on relocated instances,
> > an important category of classes that can benefit from relocation is
> > guard classes; those that perform important work maintaining invariants
> > in their destructors. If instances of such classes are to be moved
> > around - and sometimes this is unavoidable, even with C++17 temporary
> > materialization - then they need to have a move constructor that tags
> > the moved-from instance such that its destructor does not perform the
> > work. Sometimes this can be done by setting a pointer member to nullptr,
> > for example, but often a bool data member is necessary. All this work
> > could be avoided if move were replaced with relocation, since the
> > destructor would be called exactly once.
>
> Sure, but this isn't the proposal at hand.
>
> If I am not mistaken (please correct me), I think you're proposing a
> *stronger* form of relocation, specifically one where the relocation
> operation also ceases the lifetime, so the destructor isn't called
> later. I'm talking about the proposal as it is, in which there's always
> the need for such extra state, as the destructor is indeed invoked after
> a reloc.
>
Yes, that's correct. I don't think there's sufficient motivation for
pursuing relocation if it's just a slightly stronger form of move.
std-proposals_at_[hidden]> wrote:
> On 02/05/2022 15:27, Edward Catmur via Std-Proposals wrote:
> > Do you have examples of such classes?
> >
> >
> > From my perspective, and this is predicated on relocation ending
> > lifetime such that the destructor is not called on relocated instances,
> > an important category of classes that can benefit from relocation is
> > guard classes; those that perform important work maintaining invariants
> > in their destructors. If instances of such classes are to be moved
> > around - and sometimes this is unavoidable, even with C++17 temporary
> > materialization - then they need to have a move constructor that tags
> > the moved-from instance such that its destructor does not perform the
> > work. Sometimes this can be done by setting a pointer member to nullptr,
> > for example, but often a bool data member is necessary. All this work
> > could be avoided if move were replaced with relocation, since the
> > destructor would be called exactly once.
>
> Sure, but this isn't the proposal at hand.
>
> If I am not mistaken (please correct me), I think you're proposing a
> *stronger* form of relocation, specifically one where the relocation
> operation also ceases the lifetime, so the destructor isn't called
> later. I'm talking about the proposal as it is, in which there's always
> the need for such extra state, as the destructor is indeed invoked after
> a reloc.
>
Yes, that's correct. I don't think there's sufficient motivation for
pursuing relocation if it's just a slightly stronger form of move.
Received on 2022-05-02 13:59:37