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.
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?
In C++ parlance, std::vector requires that the object it stores are copyable. std::vector expects to be able to copy objects as it reallocates or if existing objects are added to it.Im basically forcing the class to work inside vectors. (that Im assuming to require a copy ctor)
C++ is a value oriented language by default. This means that unless you take care, C++ is going to create copies of things. In addition, as you found out here, C++ is going to generate copy constructors (and assignment operators) where possible to enable this behaviour.Yeah, but the issue is knowing when you going to need it...
I'd probably start with a std::vector of std::unique_ptr<TileMap>, and also make TileMap noncopyable to prevent mistakes.What should I do?
Well, given that a raw array is totally different from a dynamic container, this isn't exactly a fair comparison. You could create a std::vector, reserve() sufficient memory and emplace_back() whatever instances you need.Having used another raw array (for TileMap) in the first place would have never caused me problems, isnt it ironic?
This changes with C++11, which allows non-copyable objects if they are moveable. Of course you would need to properly implement your move constructor and move assignment operators so the amount of work is about the same.In C++ parlance, std::vector requires that the object it stores are copyable. std::vector expects to be able to copy objects as it reallocates or if existing objects are added to it.Im basically forcing the class to work inside vectors. (that Im assuming to require a copy ctor)
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.
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.
