Sign in to follow this  
freeworld

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

Recommended Posts

freeworld    341
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?

[code]
RESOURCE(const td::RESOURCE& _resource) {
*this = _resource;
};

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

Share this post


Link to post
Share on other sites
way2lazy2care    790
[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?

[code]
RESOURCE(const td::RESOURCE& _resource) {
*this = _resource;
};

RESOURCE& operator = (const td::RESOURCE& _resource) {
type = _resource.type;
amount = _resource.amount;
icon = _resource.icon;
return *this;
};
[/code]
[/quote]
http://icu-project.org/docs/papers/cpp_report/the_anatomy_of_the_assignment_operator.html

see the bit on copy vs assignment.

Share this post


Link to post
Share on other sites
jyk    2094
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 this post


Link to post
Share on other sites
Mussi    4407
[quote name='way2lazy2care' timestamp='1306778139' post='4817589']
[url="http://icu-project.org/docs/papers/cpp_report/the_anatomy_of_the_assignment_operator.html"]http://icu-project.o...t_operator.html[/url]

see the bit on copy vs assignment.
[/quote]
That was a very interesting read!

Share this post


Link to post
Share on other sites
freeworld    341
[quote name='way2lazy2care' timestamp='1306778139' post='4817589']
[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?

[code]
RESOURCE(const td::RESOURCE& _resource) {
*this = _resource;
};

RESOURCE& operator = (const td::RESOURCE& _resource) {
type = _resource.type;
amount = _resource.amount;
icon = _resource.icon;
return *this;
};
[/code]
[/quote]
[url="http://icu-project.org/docs/papers/cpp_report/the_anatomy_of_the_assignment_operator.html"]http://icu-project.o...t_operator.html[/url]

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.

[quote name='jyk' timestamp='1306803994' post='4817717']
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).
[/quote]

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 this post


Link to post
Share on other sites
jyk    2094
[quote name='freeworld' timestamp='1306810957' post='4817737']
I like to stick to the rule of three, and like to cover my basics.[/quote]
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 this post


Link to post
Share on other sites
rip-off    10976
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):
[code]
class noncopyable
{
protected:
noncopyable()
{
}

private:
// Deliberately private and unimplemented, do not copy instances of this class!
noncopyable(const noncopyable &);
noncopyable &operator=(const noncopyable &);
};
[/code]
Any non POD class can privately derive from noncopyable.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this