Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualKing Mir

Posted 02 March 2014 - 10:08 PM

Its not empty, its a copy  ctor that works like the already implemented ctor.

Im basically forcing the class to work inside vectors. (that Im assuming to require a copy ctor)

A copy constructor is defaultly generated for you, so there's no point in writing it out yourself if there's no difference from the default behavior. Which is enough if your class doesn't manage a resource.

 

 

You could write a macro to delete the default copy and assignment operator, if that suits your favor. But it doesn't do any good to put in empty methods.

The rule of three doesn't say that every class needs those three functions. It says that if it needs one of the three, then it probably needs the other two.

Yeah, but the issue is knowing when you going to need it, thus the private ones would show you instantly.

 

You need it when your class manages a resource. For example, when you dynamically allocate an array. You should use the most narrow class you can to manage each resource, with at most one resource per class. Dynamic arrays are almost never necessary because you can use std::vector.

 

Thinking deeper on it, that class should be never copied..

 

See, the thing is, I merely wanted to allocate n tilemaps at beginning and then never mess with it again.

TileMap is a private struct, so its use is really scoped, its merely an aux.

There would never be the need of copying stuff around, if it where not by std::vector.

 

Copying InstancedSprites doesnt make any sense and should not be done. And it doesnt need to be done in my code.

 

Basically, the usage of std::vector was the problem in the first place. The fact that it have a friendly interface but with implicity complexities pisses me off.

Now, I dont want to have a cpy ctor on InstancedSprites, but I do want an array of tile maps, and I need to choose the size at initialization..What should I do?

Having used another raw  array (for TileMap) in the first place would have never caused me problems, isnt it ironic?

You should have an std::array<TileMap> each tile having a std::vector<int>. You should also avoid raw pointers that signify ownership. Prefer std::vector or smart pointers like std::unique_ptr.


#2King Mir

Posted 02 March 2014 - 10:05 PM

Its not empty, its a copy  ctor that works like the already implemented ctor.

Im basically forcing the class to work inside vectors. (that Im assuming to require a copy ctor)

A copy constructor is defaultly generated for you, so there's no point in writing it out yourself if there's no difference from the default behavior. Which is enough if your class doesn't manage a resource.

 

 

You could write a macro to delete the default copy and assignment operator, if that suits your favor. But it doesn't do any good to put in empty methods.

The rule of three doesn't say that every class needs those three functions. It says that if it needs one of the three, then it probably needs the other two.

Yeah, but the issue is knowing when you going to need it, thus the private ones would show you instantly.

 

You need it when your class manages a resource. For example, when you dynamically allocate an array. You should use the most narrow class you can to manage each resource, with at most one resource per class. Dynamic arrays are almost never necessary because you can use std::vector.

 

Thinking deeper on it, that class should be never copied..

 

See, the thing is, I merely wanted to allocate n tilemaps at beginning and then never mess with it again.

TileMap is a private struct, so its use is really scoped, its merely an aux.

There would never be the need of copying stuff around, if it where not by std::vector.

 

Copying InstancedSprites doesnt make any sense and should not be done. And it doesnt need to be done in my code.

 

Basically, the usage of std::vector was the problem in the first place. The fact that it have a friendly interface but with implicity complexities pisses me off.

Now, I dont want to have a cpy ctor on InstancedSprites, but I do want an array of tile maps, and I need to choose the size at initialization..What should I do?

Having used another raw  array (for TileMap) in the first place would have never caused me problems, isnt it ironic?

You should use std::array. You should also avoid raw pointers that signify ownership. Prefer smart pointers like std::unique_ptr.


#1King Mir

Posted 02 March 2014 - 10:04 PM

Its not empty, its a copy  ctor that works like the already implemented ctor.

Im basically forcing the class to work inside vectors. (that Im assuming to require a copy ctor)

A copy constructor is defaultly generated for you, so there's no point in writing it out yourself if there's no difference from the default behavior. Which is enough if your class doesn't manage a resource.

 

 

You could write a macro to delete the default copy and assignment operator, if that suits your favor. But it doesn't do any good to put in empty methods.

The rule of three doesn't say that every class needs those three functions. It says that if it needs one of the three, then it probably needs the other two.

Yeah, but the issue is knowing when you going to need it, thus the private ones would show you instantly.

 

You need it when your class manages a resource. For example, when you dynamically allocate an array. You should use the most narrow class you can to manage each resource, with at most one resource per class. Dynamic array are almost never necessary because you can use std::vector.

 

Thinking deeper on it, that class should be never copied..

 

See, the thing is, I merely wanted to allocate n tilemaps at beginning and then never mess with it again.

TileMap is a private struct, so its use is really scoped, its merely an aux.

There would never be the need of copying stuff around, if it where not by std::vector.

 

Copying InstancedSprites doesnt make any sense and should not be done. And it doesnt need to be done in my code.

 

Basically, the usage of std::vector was the problem in the first place. The fact that it have a friendly interface but with implicity complexities pisses me off.

Now, I dont want to have a cpy ctor on InstancedSprites, but I do want an array of tile maps, and I need to choose the size at initialization..What should I do?

Having used another raw  array (for TileMap) in the first place would have never caused me problems, isnt it ironic?

You should use std::array. You should also avoid raw pointers that signify ownership. Prefer smart pointers like std::unique_ptr.


PARTNERS