Re: error deleted copy const on move

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 12 May 2021 at 22:48, Kai via Gcc-help <gcc-help@xxxxxxxxxxx> 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.



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux