wow, thanks Eyal to highlight it, what a coincidence.
In my case, it came out from standard careful read
while I was forwarding existing information for an
internal upskill for colleagues.
That said, let me provide answers to Marcin and you, in turn.
For Marcin:
> I recall this discussion but was this even in single inhrace case too?
> And if in this simple case the compiler does multiple moves, could this means
> that the code created by compiler correctly move all data?
> Like my example in my prev email, I did multiple moves but as a whole
> it only "move data" once and does not override it after that.
> And this idiom can be safely nested as only most outer function
> have data and rest do empty moves.
I would say, the point is not whether the compiler can do it simply or not
in special cases. The point is that the standard keeps it "unspecified"
in any case. To me, it means we cannot use it at all. This links to another
part of your statement:
<
I did multiple moves but as a whole
it only "move data" once
and does not override it after that >
First, this would be a contradiction. If the operation is done multiple times,
then it must move from the source multiple times. Or, at least, the current
wording from the standard should be clarified. Such a kind of 'final effect
as if the move happens exactly once' was my hope when I first posted the
showing that moving twice destroys the information in both source and
destination. This means that the compilers implementation are really
following the standard wording about the option to perform the move
multiple times.
About you, Eyal, I see interesting in the stack overflow thread this information:
there was a change from C++11 to C++14.
Before C++14, we had that in case of virtual base classes the move assign.op.
was defined as deleted, and we had the 'unspecified' only for the copy assign.op.
In my opinion, this should be reverted. It makes no sense at all to unspecifiy
for the move, which means we cannot use it at all.
About the cases when it would be complicated to get or not a "good" implicit
definition... again, I am not necessarily asking for that. It would be an option,
but I prefer to have it defined as deleted, simple and consistent.
We are having a hot time for C++ around safety.
IMHO, having an implicit definition that cannot guarantee at all not to destroy
the information, means to go against safety.
No guarantee there means useless. More, it means dangerous, because we
might have it both implicitly declared and implicitly defined.
We should not bet by relying that the compiler will do it correctly, at least
for our simple class. If the standard keeps it unspecified, we risk, and even if
we verify our current compiler works well, who assures for next version or with
stating that the additional change 1806 was a consequence
of the resolution for the issue 1402.
However, 1402 mainly focused on the non-triviality for constructors
and assignment operators, and THEN also worked on virtual base
scenarios.
So, one the one hand, 1402 avoided to uselessly have too many
cases with deleted move operations, but in my opinion it finally
led to reach the opposite... too many cases with an implicit definition.
I am convinced once more that the "unspecified" for move assign.op.
in case of virtual base classes is dangerous. An alternative should
be placed in the standard. The simplest: define as deleted.
Others are possible, but this is matter of discussion.
Mauro.