thank you for the answer.

Then, I wonder a bit that the standard just reads 'unspecified'.

To me, for the move case, it appears more like an undefined

behavior.

I mean, the 'multiple times' is a restriction about the behavior

(that cannot just be 'everything'), but at least a Note would

be fair in my opinion, still not considerable like tutoring,

because we completely lose the goal of moving, very

different from the case of 'copy' for which it is totally fair to

assume the idempotence of the operation (like the

assumptions made when copy elision is applied).

Isn't it ?

Il giorno sab 4 lug 2026 alle ore 17:54 Ville Voutilainen <ville.voutilainen@gmail.com> ha scritto:

On Sat, 4 Jul 2026 at 18:18, mauro russo via Std-Discussion
<std-discussion@lists.isocpp.org> wrote:
>
> in [class.copy.assign]-p(12.3) :
>
> It is unspecified whether subobjects representing virtual base
> classes are assigned more than once by the implicitly-defined
> copy/move assignment operator.
>
>
> I see no problem here about copy-case, but for the move-case,
> wouldn't it be an error to move more than once ?
> Is it really unspecified whether the compiler would perform the
> move more than once ? It's like inhibiting the use of the implicit
> definition for virtual base classes where move-semantics makes
> sense. I mean, if the first move changes the source subobject
> state, then second move would get from the subobject which
> by then has a modified state.
> Is there any other rule to in the standard that forces the compiler
> to assure a consistent result ? (e.g., leading to unspecified
> multiple move only in case move falls back to copy).

It is really unspecified, there is no such other rule, and GCC and
Clang do move-assign the virtual base subobject twice:
https://godbolt.org/z/PK3GEav13

Program accordingly.