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

[Greg Chicares]

On 7/28/22 16:40, Vadim Zeitlin wrote:
> On Thu, 28 Jul 2022 14:08:27 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> On 7/23/22 15:41, Vadim Zeitlin wrote:
[...]
> GC> > GC> Suppose lmi copies an object, and I want to consider moving it 
> instead.
> GC> > GC> I can write the move operation, but will move semantics actually 
> take
> GC> > GC> place, or will the compiler silently substitute a copy to fulfill my
> GC> > GC> move request? I don't simply want to make the request; I want to 
> know
> GC> > GC> how it's fulfilled. If moving is inherently impossible for some 
> class,
> GC> > GC> I'd like to know that before I waste time trying to move it.
> GC> > 
> GC> >  I think the simplest way of answering this question is to declare the 
> move
> GC> > constructor as default and rely on clang -Wdefaulted-function-deleted to
> GC> > tell you if it turns out that your move ctor is implicitly deleted. 
> Isn't
> GC> > it?

I'm not sure--see example below.

> GC> Suppose the chronology is:
> GC>  1. I write a class that's effectively-movable, but don't actually move 
> it yet.
> GC>  2. I change the class in a way that spoils its movability.
> GC>  3. A decade later, I try to move it, and find that I can't.
> GC> Doesn't clang give that warning only at the third step, where I want it
> GC> at the second?
> 
>  No, it does give it at step (2) if it gives it at all. The warning
> (-Wdefaulted-function-deleted) is given as soon as the class is declared,
> there is no need to use it at all. E.g. here is a stupid but self-contained
> example: [...snipped example...]

In the modified example below, struct 'non_movable' is constructible and
assignable from 'non_movable&&' by using copy semantics, but not, AIUI,
by using move semantics. I expected clang to diagnose implicit deletion
of the move constructor, but it doesn't.

 - isn't 'base' non-moveable?

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

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

$ cat >eraseme.cpp <<'EOF'
struct base
{
    ~base() = default; // this dtor makes move functions "undeclared"
};

struct non_movable : base
{
    non_movable() = default;
    non_movable(non_movable const&) = default;
    non_movable(non_movable&&) = default;
    non_movable& operator=(non_movable const&) = default;
    non_movable& operator=(non_movable&&) = default;
};
EOF

$ clang++ -fsyntax-only -Wall -std=c++20 eraseme.cpp && echo "Okay"
Okay