Jump to content
  • Advertisement
Sign in to follow this  
freeworld

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

This topic is 2605 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?


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


Link to post
Share on other sites
Advertisement

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


Link to post
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 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):

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!