0

I encountered some code where one guy has overloaded copy constructor and assignment operator, like this:

 Prod(const Prod& src) {  
        _id    = src._id;
        _name  = src._name;
        _group = src._group;
        ...
}

 Prod& operator=(const Prod& src) {  
        _id    = src._id;
        _name  = src._name;
        _group = src._group;
        ...
}

The thing I find strange is that none of the member variables in the Prod class are pointers. So why is there a need to overload the copy constructor and = operator as above?

pseudonym_127
  • 357
  • 7
  • 16

2 Answers2

5

If the class doesn't manage resources, then you're right, there's no need to overload them. If it's used as a base class and it has a virtual destructor, they're probably there to obey the rule of three, although the C++11 alternative = default would be cleaner than actually implementing them.

On a side-note, the copy constructor can be implemented using operator = to avoid duplicating the logic:

Prod(const Prod& src) {  
   *this = src;
}
quetzalcoatl
  • 32,194
  • 8
  • 68
  • 107
Luchian Grigore
  • 253,575
  • 64
  • 457
  • 625
  • 4
    Implementing the copy constructor with the help of the assignment operator is quite wrong conceptually, a constructor constructs, it doesn't assign (assign to what there isn't anything yet, a default constructed object you say, well this isn't a copy constructor then, is it?). Apart from defining them at all, that was one of the errors of that *"one guy"* from the question, too. – Christian Rau Jul 08 '13 at 08:34
  • @ChristianRau you could also do the reverse: implement the assignment operator using the copy constructor (using placement `new`). – Walter Jul 08 '13 at 09:15
  • 2
    @Walter assignment using copy ctor yes, by the copy&swap idiom. Using placement new: never ever do that. Your'e messing with object lifetimes here, i.e. destroying and creating an object whilst pretending it continues to exist. – Arne Mertz Jul 08 '13 at 09:17
  • @ArneMertz It's dangerous, but not illegal (and I never ever do that). However, it should allow to implement an assignment operator legally even for types holding non-assignable data, such as references. – Walter Jul 08 '13 at 18:32
3

There was a rule of three and then there's now s a rule of five which are very likely to be superseded in a rule of zero.

Maybe someone wasn't sure wand just added some extra code.. ;)

In general, when all of the member fields are simple or automatically managed (that is, with proper ctors, copyctors, movectors, assignement, dtors etc), then there's no point in writing anything. See the rule-of-zero. However, this may a part of a code that was created under older version of the standard or at some compiler that was, well, hairy, and it might have been required at some point of time in the past. Now probably you may delete it and leave to default implementations.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
quetzalcoatl
  • 32,194
  • 8
  • 68
  • 107