3

So if I've got a class and declare a copy assignment operator in it, obviously I want some special behavior when copying. I would expect the language to try to help me out by implicitly deleting the copy constructor until I explicitly bring it back, so as to avoid unintended different behavior when doing type instance = type() as opposed to already_existing_instance = type().

It's recommended anyway that you explicitly declare both copy constructor and copy assignment operator when trying to declare one of them, precisely because C++ doesn't delete the other and causes you a headache.

An example of where I find this annoying is when deleting the copy assignment operator. If I want to quickly make a class non-copyable, I would expect deleting the copy assignment operator does the trick, but I have to explicitly delete the copy constructor as well.

My question is why does the compiler do this? Who thought this was a good idea? All it does is create a needless obstacle for the programmer or am I missing something?

P.S. This behavior doesn't present itself when doing the same thing with move constructors/assignment operators, why make a distinction between copy and move in this case?

Improve this question
4
  • 1
    Compilers tend to have a warning when there's custom copy ctor but not copy assignment an vice versa. This is inheritance from pre-C++11 when one couldn't default said operations. Commented Nov 21, 2022 at 17:48
  • @ALX23z Can you elaborate on what you mean when you say "one couldn't default said operations"? My examples don't use the default keyword, are you referring to something else? Commented Nov 21, 2022 at 17:54
  • It might, one day timsong-cpp.github.io/cppwp/n4868/… timsong-cpp.github.io/cppwp/n4868/class.copy.ctor#6.sentence-3 Commented Nov 21, 2022 at 17:59
  • By defaulting, I mean writing = default. So when one couldn't do it, if say, default copy ctor was disabled for whatever reason then you'd have to write the full implementation manually even if you wanted the default one. Commented Nov 21, 2022 at 18:02

1 Answer 1

Reset to default
3

Them not being deleted is deprecated.

E.g. Clang 15 with -Wextra, given

struct A { A() {} A(const A &) {} }; int main() { A a, b; a = b; }

spits

<source>:4:5: warning: definition of implicit copy assignment operator for 'A' is deprecated because it has a user-provided copy constructor [-Wdeprecated-copy-with-user-provided-copy] A(const A &) {} ^ <source>:10:7: note: in implicit copy assignment operator for 'A' first required here a = b; ^

Similarly,

struct A { A() {} A &operator=(const A &) {return *this;} }; int main() { A a, b(a); }

gives

<source>:4:8: warning: definition of implicit copy constructor for 'A' is deprecated because it has a user-provided copy assignment operator [-Wdeprecated-copy-with-user-provided-copy] A &operator=(const A &) {return *this;} ^ <source>:9:10: note: in implicit copy constructor for 'A' first required here A a, b(a); ^
Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

Absolutely fantastic. Just to make sure I'm not misunderstanding, deprecation means they'll be removing it in the future, correct?
@NikTedig Hopefully yes.
@NikTedig -- deprecated means it might be removed in the future. It's not a promise; it's a warning.
...or more of a threat.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.