I was wondering if it's safe to write a reset
method of some class A
by using the move assignment operator on this
.
So instead of
A a{};
... // Do something with a
a = A();
if I could write
A a{};
... // Do something with a
a.reset();
where
void A::reset()
{
*this = A();
}
I played arround a bit on godbolt (https://godbolt.org/z/Edc3TT1aT ) and the resulting debug assembly is almost identical with gdb for this example.
operator=
, and the class having proper ownership management of resources in its member variables.) – Declaratory*this = std::move(A());
be safer? Or is that unnecessary? I'm thinking about possible side-effects of the source (local)A
being destroyed when it goes out of scope; but maybe I'm just confused. – Forthright*this = std::move(A());
and*this = A();
does the same thing – Eckhart*this = A();
is already a prvalue,std::move
would not improve things at all (there are some cases where it makes things worse, e.g. in function return values where the use ofstd::move
inhibits copy-elision and causes an unnecessary move and destruction, while returning it directly invokes no constructors at all). – Shelleyshellfirestd::move
from named objects (strictly speaking, lvalues, to convert them to xvalues [a type of rvalues]) or things attached to named objects (e.g. indexing or attributes). There are exceptions (with compilers supporting NRVO, you want to avoid it for function return values), but in general, if you're assigning from an object with a name in the current scope (not something returned by a function call, not something constructed directly in the expression),std::move
can help, but if there is no "thing" to move from, it's pointless at best. – Shelleyshellfire