On Monday, 1 June 2015 at 14:43:22 UTC, Marc Schütz wrote:
On Monday, 1 June 2015 at 14:20:46 UTC, Jonathan M Davis wrote:
On Monday, 1 June 2015 at 12:50:28 UTC, Marc Schütz wrote:
Also, object with destructors need to have more restrictions:
S {
~this();
}
void foo() {
S s;
if(condition)
bar(s);
// <- should we run the destructor here?
}
This can either be solved by making such cases non-eligible,
or by "remembering" whether an object was moved using a
hidden boolean variable. AFAIK the latter is incidentally the
solution Rust chose.
Wouldn't the compiler just do something like
if(condition)
{
bar(s); // Do a move; the destructor is run inside bar
return;
}
else
{
s.__dtor();
return;
}
In which case, the destructor is always run in the right spot,
and the compiler can guarantee that a move is done rather than
a copy?
When this can be done, it's of course a good solution. But when
there is additional code between the move and the destruction,
it usually doesn't work:
void foo() {
S s;
if(condition)
bar(s);
baz();
// <- should we run the destructor here?
}
Then, like you suggested, that would indeed appear to require
either an invisible bool that indicates whether a move was done
or not or disallowing the move. I think that I'd favor the bool,
since moving is likely to save more than the extra bool is going
to cost.
- Jonathan M Davis