Jump to content
  • Advertisement
Sign in to follow this  
Alundra

NonCopyable everywhere ?

This topic is 1055 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

Hi,

Are you using NonCopyable everywhere even if the class is only a pointer to be safe about :

*A = *B

Thanks

Share this post


Link to post
Share on other sites
Advertisement
I don't really understand what you are asking. "*A = *B" together with your text does not make sense to me.

In most cases copyable or not copyable should solve itself in modern code. Anything that manages resources in some non-trivial way should do that in a class that is as atomic as possible (std::unique_ptr and std::shared_ptr are two examples of this). Anything more complex should be automatically (non-)copyable, (non-)movable by the nature of the member data. For example anything containing a std::unique_ptr<>-member will not be copyable.

Share this post


Link to post
Share on other sites
I don't really understand what you are asking. "*A = *B" together with your text does not make sense to me.

Because when you do *A = *B, it calls the operator = and if the class is not safe to allow it, it's a security problem then.

Edited by Alundra

Share this post


Link to post
Share on other sites
That has nothing to do with pointers. "A = B" when A and B are pointer-less instances is the exact same problem. "*A = B" and "A = *B" with adequate types is the same. Edited by BitMaster

Share this post


Link to post
Share on other sites

Because when you do *A = *B, it calls the operator = and if the class is not safe to allow it, it's a security problem then.

 

Security problem? No, it's just an API usability problem.

 

If you don't want people to unintentionally copy your class, derive from NonCopyable, or  if you're using c++11, declare the assignment operator (and copy constructor) and mark it delete.

Edited by phil_t

Share this post


Link to post
Share on other sites

Security problem? No, it's just an API usability problem.


Not completely. If you just copy things around without any thought you can quickly come into a situation where your ownership is completely messed up and you double-delete or access deleted (or worse, already reallocated) memory. That's a crash problem to start with and can end up being a security problem when confronted with a determined attacker.

Share this post


Link to post
Share on other sites

The main reason is usually doing things like having "new" in the constructor and "delete" in the destructor. Any accidental temporary copy would typically cause a double delete eventually (or worse, leave your original with an invalid pointer for a long time, only crashing much later and being a real pain to debug).

 

One solution is explicitly deleting all problem operations (assignment, copy construction, etc.)

 

A typically better solution is to properly express your ownerships by using the correct smart pointer. In the above case, use a unique_ptr instead of a raw pointer and suddenly code that would accidentally (or intentionally) copy or assign won't compile. Problem solved without messing about with deleting default functions. If data should be shared, use a shared_ptr and data is automatically deleted at the proper point. In both cases, you don't need to worry about manually deleting anything.

 

Just making literally everything noncopyable for no good reason would simply look like unreflected cargo cult programming (yes, it's a thing and scarily common).

Edited by Trienco

Share this post


Link to post
Share on other sites

I keep finding non-copy and non-move on things that should have one or both. It's like shorthand for "I don't know how to write proper copy/move ctors".

 

If you want a class which owns a resource to be copyable then you have to copy the resource. If you want it to be movable then you have to transfer the resource and then break it's ownership ties in the original object.

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!