Re: [lmi] Detecting whether move semantics actually take place

[Vadim Zeitlin]

On Sun, 31 Jul 2022 00:41:37 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> In the modified example below, struct 'non_movable' is constructible and
GC> assignable from 'non_movable&&' by using copy semantics, but not, AIUI,
GC> by using move semantics.

 It does use move semantics.

GC>  - isn't 'base' non-moveable?

 It is still moveable because it doesn't forbid moving by deleting its move
ctor. It's moved by copying it, but this is just its implementation detail
and doesn't concern its derived classes.

GC>  - isn't 'non_movable' non-moveable because it's derived from 'base'?

 It is still movable...

GC>  - isn't the explicitly defaulted "non_movable(non_movable&&)" therefore
GC>      implicitly deleted?

... and hence this is not the case.

 I can prove this experimentally:
---------------------------------- >8 --------------------------------------
% cat non_movable.cpp
#include <stdio.h>
#include <utility>

struct base {
    ~base() = default;
};

struct non_movable : base {
    non_movable() = default;
    non_movable(non_movable const&) { puts("copy ctor"); }
    non_movable(non_movable&&) { puts("move ctor"); }

    const int value = 17;
};

int main() {
    non_movable x;
    return non_movable{std::move(x)}.value;
}
% g++ -std=c++20 -Wall non_movable.cpp && ./a.out || echo $?
move ctor
17
---------------------------------- >8 --------------------------------------

which is not the best kind of proof, of course, but it would sense to me if
the derived class was still movable unless the base class explicitly forbid
it.

 And, in fact, if you do add "base(base&&) = delete" to the base class
declaration, then you would get warnings (and even errors, as the code
above actually tries to use the deleted move ctor, but the warning would be
given just for the class declaration, without main() definition) from
clang.

 Regards,
VZ

pgpdP85Z64CVD.pgp
Description: PGP signature