Sign in to follow this  

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

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

If you intended to correct an error in the post then please contact us.

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?

[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
[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
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
[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
[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
[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
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

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

If you intended to correct an error in the post then please contact us.

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