Date: Thu, 22 Dec 2022 22:24:09 -0300
On Thursday, 22 December 2022 08:17:40 -03 Sebastian Wittmeier via Std-
Proposals wrote:
> If the destructor is called on the reference, the original object would be
> destroyed.
How does it prevent the original object, which may not be in the current
scope, from doing a double-destroy?
void f(MyType &b)
{
reloc b;
}
You can say that it's the caller's responsibility, which I find there may be
good reasons for. For example, b could be stored in an optional-like holder
that can be told to drop the contents on the floor as having already been
destroyed.
But that's hardly RAII. If MyType is relocatable, then one could have simply
extracted it off from the optional-like holder via return-by-value instead of
pointing to the object inside the optional-like.
But then this means that you can't do some operations on a non-const lvalue
reference that you can on real objects. That's weird language break.
Proposals wrote:
> If the destructor is called on the reference, the original object would be
> destroyed.
How does it prevent the original object, which may not be in the current
scope, from doing a double-destroy?
void f(MyType &b)
{
reloc b;
}
You can say that it's the caller's responsibility, which I find there may be
good reasons for. For example, b could be stored in an optional-like holder
that can be told to drop the contents on the floor as having already been
destroyed.
But that's hardly RAII. If MyType is relocatable, then one could have simply
extracted it off from the optional-like holder via return-by-value instead of
pointing to the object inside the optional-like.
But then this means that you can't do some operations on a non-const lvalue
reference that you can on real objects. That's weird language break.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2022-12-23 01:24:13