Storing Sprites In A Vector?

[Jesper Juhl]

... but if it was a reference or a smart pointer, then move has to be considered (That or refactoring).

You can't have a container of references.
Besides, "move" is mainly (very close to "only") an optimisation. You never *have* to move. And when it comes down to it, std::move is just a cast to r-value reference, it generates absolutely no code. So if the types involved don't support moving it will do nothing of value - you'll still just fall back to copy.

[Gambit]

I meant reference wrapper as Dienes noted before, and you do HAVE to move when you are using things like unique pointers.

[Jesper Juhl]

Of course you have to move when dealing with move-only types. But that's still well into advanced territory and the original question was not even close to that..

[Gambit]

Just let it go, the question has been solved and our dispute over move semantics has been put to rest.

[Robustprogram]

Instead of doing this:

std::vector<*Sprite> sprites;
Sprite sprite1;
sprites.push_back(&sprite1);
 

So I am wondering if there is any problems with this implementation.

This does almost the same thing as above, except it leaks memory because now the vector's destructor won't be able to clean up the copy of sprite1.

The moral is: never use raw owning pointers in modern C++ without a VERY good reason.  You won't need them.  Also avoid using pointers of all kinds because you won't need any of them very often, and even smart pointers are always going to be more error prone than ordinary stack-based objects.  If your program has no pointers in it, you simply can't make most of the common memory management mistakes.

Sorry to bump this post but how come the vector's destructor won't be able to clean up the copy of sprite1? Clear me up if I am wrong but the way I see it is that the vector will store the references to the objects instead of the object itself. But since it has the reference, wouldn't it be still be able to clean it up? Sorry if I sound dumb right now.

[Ixrec]

The vector's destructor will invoke the destructors of all the objects it contains.

sf::Sprite is a class, so it will have a destructor that cleans up everything.  So std::vector<sf::Sprite> is fine.

A pointer to sf::Sprite is just a pointer.  In terms of construction and destruction, it may as well be an int or a float or something.  The vector will free the heap-allocated memory it was using to store the int/float/pointer as usual, but it has no way of knowing that it needs to go destruct the things pointed to by the pointers.  So a vector of raw pointers is only okay if those are "non-owning" pointers that aren't supposed to clean up the actual sprite objects, but only point to them (of course, in modern C++, a non-owning raw pointer is the only kind of raw pointer you should ever have).

This is the reason why "smart pointers" exist.  A smart pointer is essentially a class that contains a pointer, with a destructor that deletes the thing it points to.  So a vector of unique_ptrs or shared_ptrs to Sprites would clean itself up just fine.



Of course, even though smart pointers will work, most of the time there won't be any reason to use pointers of any kind.  Always use ordinary objects or references if you don't have a good reason to get pointers involved.

Note that there are some languages in which a "raw pointer" is able to "clean up after itself" and you don't need to worry about any of this.  But as far as I know, those are all garbage collected languages.  Obviously, C and C++ (normally) do not have garbage collection.

[Jesper Juhl]

Instead of doing this:

std::vector<*Sprite> sprites;
Sprite sprite1;
sprites.push_back(&sprite1);
 

So I am wondering if there is any problems with this implementation.

This does almost the same thing as above, except it leaks memory because now the vector's destructor won't be able to clean up the copy of sprite1.

Ehh. The code above is bad not for mem-leak reasons, but because it stores a pointer to a stack allocated variable into the vector. Once the stack allocated variable goes out of scope the pointer in the vector will point to garbage memory.
Or am I missing something?

[Ixrec]

You're right, I was thinking of the "normal" way of populating a container of pointers using heap allocation.  I believe I interpreted the original question (waaaay back when this thread) as being about whether a container should have objects or pointers to objects, and clearing up the confusion in Gambit's responses was more urgent so I totally forgot about the pointing to garbage memory issue.

[Robustprogram]

Ahhhhhh, thanks guys.