Why is the copy assignment operator implicitly defined?

Question

Default Constructor, Copy Constructor and Destructor are very important and I understand why C++ implicitly defined them. Just think about function arguments that should be copied, local variables that should be destructed and objects that should be construct-able even if you don't say how to construct.

But why do we need the copy assignment operator implicitly defined? Is it really a must to be able to do a = b? It is not game changing, right? Any strong reason I don't know?

Why would it make sense for something that is copyable not to be copy assignable by default? — juanchopanza, May 11 '16 at 12:36
The question is as unclear as waters of Hudson in NY Harbor. What do you mean by game changing? Nothing is game changing, people were living in caves 70000 years ago, and it didn't differ much from how we live now. — SergeyA, May 11 '16 at 13:15
@SergeyA, while you are trying to make a joke here, people answer to my question :) No offense, please. — Narek, May 11 '16 at 13:16
Well your last edit completely invalidated my looong answer. — Nick, May 11 '16 at 13:22
no problem. but question is more or less opinion based - "because we can" or "because normally we can not invoke destructor manually" — Nick, May 11 '16 at 13:53
There is actually an interesting point to this, which is _should this be the case_? It ties in to the question of whether a language should be designed to promote mutability of objects or not. Personally I'd like to see objects `const` by default, and this question is at the heart of whether or not that would ever be a good idea. _Do_ we always want to be able to assign to things by default? (Ironically, if objects were `const` by default then we probably _would_ want implicit assignment operators, because the only time they could be used is when the object were deliberately marked `mutable`.) — Lightness Races in Orbit, May 11 '16 at 17:07

score 7 · Accepted Answer · edited May 23 '17 at 12:24

7

... why do we need the copy assignment operator?

Simply, to support assignment semantics. These are not the same as copy construction semantics.

Foo f1;
Foo f2(f1); // copy...
Foo f3;
f3 = f1; // assignment...

They are similar, and often implemented in terms of one another, but not the same.

Why would they all be implicitly defined?

To support and mimic the C-style value semantics. So that user defined types can support the same semantics as the built in types.

Side note; IIRC, there has been some deprecation of rules here with the onset of move semantics...

edited May 23 '17 at 12:24

Community

1
1

answered May 11 '16 at 12:36

Niall

30,036
10
99
142

Would upvote, if not for my strong belief that the question is unclear, useless and should be closed. – SergeyA May 11 '16 at 13:15
2

@SergeyA. At your discretion. Given the edit, I think he cleared it up... except maybe the "game changer"... – Niall May 11 '16 at 13:36
So there are two reasons 1. to mimic C-style syntax and also for UDT to support the same semantics as for built-in ones. – Narek May 11 '16 at 18:56
1

@Narek. The original motivation has been refined over the years, but there was a strong desire to allow UDT to mimic built in type, this was important to support a general purpose language. Our understanding of the consequences of this has evolved over the years leading to the "rule of three", "rule of five" and "the rule of zero". Allied to this is the evolution of the formal rules regarding these special members as well - but none of these take away, in fact they add to, the motivation to support value semantics. As an aside, this is also intimately tied to the RAII mechanisms in C++. – Niall May 11 '16 at 19:33
1

@Narek, "The Design and Evolution of C++" makes for a good read. – Niall May 11 '16 at 19:49

score 4 · Answer 2 · edited May 11 '16 at 17:05

4

I believe it comes from one of the properties/capabilities of C++ which is being able to compile the native C code.

In C you are able to assign one struct variable to another e.g.

typedef struct foo_s
{
    int field1;
    int field2;
} foo_t;

int main ()
{
    foo_t a, b;

    a.field1 = 1;
    a.field2 = 2;

    b = a;

    return 0;
}

So you should be able to compile this code as C++ thus you must have a default assignment operator.

edited May 11 '16 at 17:05

Lightness Races in Orbit

378,754
76
643
1,055

answered May 11 '16 at 12:43

Alex Lop.

6,810
1
26
45

Alex, I think this is the answer of my question. So, strictly saying, this is just for backward compatibility? – Narek May 11 '16 at 13:06
Why do you say you didn't understand the question? Looks right to me. – Lightness Races in Orbit May 11 '16 at 17:04
@LightnessRacesinOrbit The original question was about assignment operator in general, not only the default one. But now I see that the question has been edited... – Alex Lop. May 11 '16 at 19:03

UniversE · Answer 3 · 2016-05-11T13:01:20.663

1

If you copy-construct an object, you are able to set const members. Imagine you already have an object and then want to do an assignment. This would violate the constness of the members.

To clarify this a bit - because this short text seemed to be not sufficient for the most people - here some code:

struct C {

  const int i;
  C(int i) :i(i) {};
};

int main(void) {

  C a(5), b(7);

  a = b; // compiler error
  C c(a);  // no error

  return 0;
}

So you need the assignment operator, because it has different semantics.

It is implicitly defined - if possible - because assignment should be defined by default whenever it is possible. Note, that in most cases your assignment operator is actually not implicitly defined. The above code is just one example, but there are many other cases: if you have a user declared move constructor for instance, then the copy assignment operator is not implicitly defined.

edited May 11 '16 at 13:01

answered May 11 '16 at 12:39

UniversE

2,419
17
24

I'm sorry but I have having a hard time understanding why this is an answer. The OP is asking why the copy assignment operator is implicitly created for us. – NathanOliver May 11 '16 at 12:40
@NathanOliver the OP also asked "why we need copy assignment operator" - and this is the answer. – UniversE May 11 '16 at 12:41
Okay he ask both but this still doesn't answer *why we need copy assignment operator* – NathanOliver May 11 '16 at 12:43
1

This doesn't even answer "why we need copy assignment operator". – juanchopanza May 11 '16 at 12:44
@juanchopanza yes it does, but maybe not clear enough. I added some code, that shows, why you need the distinction between copy ctor and copy assignment. – UniversE May 11 '16 at 13:02
@UniversE It may do so now, but it most certainly didn't before. You didn't just add some code. You actually tried to answer the question. – juanchopanza May 11 '16 at 13:03

Why is the copy assignment operator implicitly defined?

3 Answers3