• 12
• 10
• 10
• 13
• 10

Is it safe to use the assignment operator for the copy constructor

This topic is 2486 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I was thinking since the the assignment operator and the copy constructor basically do the exact same thing, Inform me if there are situations were this isn't true. Can you just define the assignment operator, and use it inside the copy constructor instead of writing the same code twice?

 RESOURCE(const td::RESOURCE& _resource) { *this = _resource; }; RESOURCE& operator = (const td::RESOURCE& _resource) { type = _resource.type; amount = _resource.amount; icon = _resource.icon; return *this; }; 

Share on other sites

I was thinking since the the assignment operator and the copy constructor basically do the exact same thing, Inform me if there are situations were this isn't true. Can you just define the assignment operator, and use it inside the copy constructor instead of writing the same code twice?

 RESOURCE(const td::RESOURCE& _resource) { *this = _resource; }; RESOURCE& operator = (const td::RESOURCE& _resource) { type = _resource.type; amount = _resource.amount; icon = _resource.icon; return *this; }; 

http://icu-project.org/docs/papers/cpp_report/the_anatomy_of_the_assignment_operator.html

see the bit on copy vs assignment.

Share on other sites
Just out of curiosity, is there any particular reason the compiler-generated versions of those function won't suffice?

Another (perhaps minor) consideration is that the copy constructor as implemented in your example will default-construct all of the member fields, and then perform the assignment. This may or may not matter, but it would be more idiomatic to construct the member fields using an initializer list (in which case you wouldn't be implementing the copy constructor in terms of the assignment operator).

Share on other sites

[quote name='freeworld' timestamp='1306774060' post='4817566']
I was thinking since the the assignment operator and the copy constructor basically do the exact same thing, Inform me if there are situations were this isn't true. Can you just define the assignment operator, and use it inside the copy constructor instead of writing the same code twice?

 RESOURCE(const td::RESOURCE& _resource) { *this = _resource; }; RESOURCE& operator = (const td::RESOURCE& _resource) { type = _resource.type; amount = _resource.amount; icon = _resource.icon; return *this; }; 

http://icu-project.o...t_operator.html

see the bit on copy vs assignment.
[/quote]

From what I understand in that article as long as I'm dealing with any memory allocation, then what I've proposed is ok.

Just out of curiosity, is there any particular reason the compiler-generated versions of those function won't suffice?

Another (perhaps minor) consideration is that the copy constructor as implemented in your example will default-construct all of the member fields, and then perform the assignment. This may or may not matter, but it would be more idiomatic to construct the member fields using an initializer list (in which case you wouldn't be implementing the copy constructor in terms of the assignment operator).

I'm just using it as an example... the code simply made me think of the question. I like to stick to the rule of three, and like to cover my basics. For this particular question speed isn't a matter. Id just rather not clutter my code unless it is necessary to prevent crashing. I just don't see what would be the problem in doing this... but I don't consider my self any where near a professional.

Share on other sites

I like to stick to the rule of three, and like to cover my basics.

Does your class have any members that require manual clean-up or deep copying? (Perhaps you could post the class in its entirety so we could take a look.)

Share on other sites
If you want to avoid clutter I recommend making classes noncopyable until the need to actually copy them arises. Most classes don't need to be copyable, in fact you generally want to pass by const reference rather than create copies. Classes that do make sense to copy are frequently POD anyway, or composed of relatively simple members.

You could use boost::noncopyable, or this (essentially the same thing):
 class noncopyable { protected: noncopyable() { } private: // Deliberately private and unimplemented, do not copy instances of this class! noncopyable(const noncopyable &); noncopyable &operator=(const noncopyable &); }; 
Any non POD class can privately derive from noncopyable.