error deleted copy const on move

error deleted copy const on move

[Kai]

G'day!

Today I was confused by an error message, gcc produced on my code.
--- Example:
#include <utility>
class NoCopy
{
public:
    NoCopy( int i ) : ei(i) {}
    NoCopy( NoCopy const& ) = delete;
//    NoCopy( NoCopy&& ) = delete;
//    NoCopy( NoCopy&& ) = default;
    int const ei;
};
void func() {
    NoCopy orig{ 42 };
    auto movy = NoCopy{ std::move(orig) };
}
--- Example end.

gcc complains that I'm trying to call the explicitly deleted copy
constructor here (last line). I checked on compiler explorer that the
latest version shows the same error message; so do clang and msvc, by
the way.

While I'm quite certain, that the error message is technically OK
(because a rvalue ref may also bind to a const lvalue ref, as far as I
remember), it still is a bit confusing for the devloper that is trying
to figure out why he did wrong.

What I'm trying to do here is calling the move constructor. That one was
implicitly deleted by explicitly deleting the copy constructor.
Interestingly enough, when I _ex_plicitly delete the move constructor,
the error message changes to correctly hint to my mishap. (Of course, on
explicitly defaulting the move constructor, the code compiles.)

So, is it a dedicated choice to reference the copy constructor in the
error message, even when the caller offers an (explicit) rvalue? Or
wouldn't it be better, to hint to the implicitly deleted move constructor?

Cheers, Kai
--
"Too proud to beg, too dumb to steal"
<Sting>
D-55120 Meenz     fon :+49 6131 6063865      fast: kaibar (aT]
posteo(dot)net
++ PGP Key fingerprint  059D 4FAA FE93 5928 1B22  7FAF EC08 5BF9 D50E
F933 ++
-----BEGIN GEEK CODE BLOCK-----
VERSION: 3.12
GCS/IT d- s: a++>-----(?) C++$ UL++(++++$) P++ L++$ E-(+) W--(+) N !w---
!O !M V? PS+ PE-() Y+ PGP++ t R@* tv--(-) b+>++ DI++ G e+++(*) h? y?
------END GEEK CODE BLOCK------

Re: error deleted copy const on move

[Jonathan Wakely]

On Wed, 12 May 2021 at 22:48, Kai via Gcc-help <gcc-help@gcc.gnu.org> wrote:
>
> G'day!
>
> Today I was confused by an error message, gcc produced on my code.
> --- Example:
> #include <utility>
> class NoCopy
> {
> public:
>     NoCopy( int i ) : ei(i) {}
>     NoCopy( NoCopy const& ) = delete;
> //    NoCopy( NoCopy&& ) = delete;
> //    NoCopy( NoCopy&& ) = default;
>     int const ei;
> };
> void func() {
>     NoCopy orig{ 42 };
>     auto movy = NoCopy{ std::move(orig) };
> }
> --- Example end.
>
> gcc complains that I'm trying to call the explicitly deleted copy
> constructor here (last line). I checked on compiler explorer that the
> latest version shows the same error message; so do clang and msvc, by
> the way.
>
> While I'm quite certain, that the error message is technically OK
> (because a rvalue ref may also bind to a const lvalue ref, as far as I
> remember), it still is a bit confusing for the devloper that is trying
> to figure out why he did wrong.
>
> What I'm trying to do here is calling the move constructor. That one was
> implicitly deleted by explicitly deleting the copy constructor.

Nope. See below.

> Interestingly enough, when I _ex_plicitly delete the move constructor,
> the error message changes to correctly hint to my mishap. (Of course, on
> explicitly defaulting the move constructor, the code compiles.)

Which is the correct way to define a class that is movable but not copyable.

> So, is it a dedicated choice to reference the copy constructor in the
> error message, even when the caller offers an (explicit) rvalue? Or
> wouldn't it be better, to hint to the implicitly deleted move constructor?

It isn't implicitly deleted though, it simply doesn't exist. There is
no move constructor. See http://eel.is/c++draft/class.copy.ctor#8

So GCC is technically correct (the best kind of correct). The only
viable constructor is the copy constructor, and that is deleted. But
that doesn't mean that the diagnostic couldn't be more helpful in
explaining things, as you're surely not the first person to
misunderstand what the language rules are, and why you get that
specific error.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89700 is related.