I see a lot of old code that has copy constructors defined, but not move constructors. This pessimizes code since the definition of the copy constructor hides the default move constructor. Would be nice to get a warning for this to recover perf. ``` #include <utility> using namespace std; struct foo { int a,b,c; // expect-warning foo(const foo &); }; foo fn(foo &&f) { foo g(move(f)); return g; } ``` https://gcc.godbolt.org/z/5r8erG
(In reply to Nuno Lopes from comment #0) > I see a lot of old code that has copy constructors defined, but not move > constructors. This pessimizes code since the definition of the copy > constructor hides the default move constructor. If you need a user-defined copy constructor, a defaulted move constructor probably isn't going to do the right thing anyway.
Also, how would users suppress this warning for cases where it's not wanted? Plenty of classes don't need a move constructor because moving is not more efficient than copying, but they don't want a defaulted move constructor. Basically, the code isn't necessarily wrong, and there's no easy way to tell whether the lack of a move constructor is a problem, or should be changed.
This is a dup, and there's additional discussion in the dup. *** This bug has been marked as a duplicate of bug 89700 ***