Issues constructing a unique pointer to sf::Sprite (Solved)

[UglyIgloo]

Hi, I'm having trouble putting an sf::Sprite inside of a unique pointer.

The following code will compile just fine without warnings or errors:

void SpriteManager::attachSprite(sf::Sprite sprite)
{
        Ptr p;
        mSprites.push_back(std::move(p));
}

Ptr is a typedef to this:

typedef std::unique_ptr<sf::Sprite>             Ptr;

When I try to construct a Ptr p with a sf::Sprite like this, however, I get an error.

void SpriteManager::attachSprite(sf::Sprite sprite)
{
        Ptr p(sprite);
        mSprites.push_back(std::move(p));
}
 

1>SpriteManager.cpp(12): error C2664: 'std::unique_ptr<_Ty>::unique_ptr(std::nullptr_t)' : cannot convert parameter 1 from 'sf::Sprite' to 'std::nullptr_t'

Which I don't really understand, because I thought arguments taken from a unique_ptr's constructor defined their pointer. If someone could help address this issue, that'd be great.


Thanks!

[Gambit]

Try:

using Ptr = std::unique_ptr<sf::Sprite>;
void SpriteManager::attachSprite(std::Sprite sprite)
{
   Ptr p{new sf::Sprite{sprite}};
   mSprites.push_back(std::move(p));
}
 

[UglyIgloo]

This worked. Thank you!

[Nexus]

When your compiler already supports C++14, you don't even need to mention new:

auto ptr = std::make_unique<sf::Sprite>(sprite);
mSprites.push_back(std::move(ptr));

But why do you store sprites in unique pointers? Why this indirection if you don't use inheritance?
std::vector<sf::Sprite> would be simpler and probably more efficient.

[UglyIgloo]

I'm using Visual Studio 2010, sorry.


Also, I thought that you couldn't store objects in vectors without calling new? Every time I try storing sprites in vectors without it, I would get errors, which is why I make it a unique pointer.

[Jesper Juhl]

Time to read up on C++ before moving on. Learn the language properly and many problems go away.

Edit: and do yourself a favor and use a modern compiler.

[UglyIgloo]

I'm at that frustrating stage of C++ where I "know" the language well enough to pretty much make anything, but not enough to do it right. Going through any crash course/ tutorial series/ C++ book would just be a bore for me since it will be covering the stuff I already know.

[Gambit]

Just copy. Use std::vector<sf::Sprite>.

[UglyIgloo]

Sorry for the stupid questions.


Isn't copying kind of "bad" practice for something like managing sprites in a scene class?

[Jesper Juhl]

sf::Sprite is a very light-weight class. Copying it won't impact your applications performance. Don't worry about it.

[Ixrec]

Copying is not automatically evil.  All the STL containers make copies when you add elements to them.  A sprite in particular is a very lightweight object.  It's just some numbers and a pointer to a texture.

Worrying about minimizing copies when you have a concrete performance problem caused by excessive copies.

[Gambit]

Ixrec and I had a lengthy back-and-forth but he is right in that copying in most cases is fine. Large/cluncky/unoptimized/poorly implemented classes might have poor performance when copying but for sf::Sprite and pretty much everything copyable in SFML is fine to copy.

[UglyIgloo]

Just one more question:

Like I said before, this is pretty much a scene manager, which means that all the sprites in one scene are stored in this class until they're deleted. If I'm copying, how will I make a reference to a specific instance of a sprite?


Thanks for bearing with me for this long.

[Gambit]

For a scene manager you will probably want to use unique pointers then, but it really comes down to how you want the design.

[Ixrec]

Just one more question:

Like I said before, this is pretty much a scene manager, which means that all the sprites in one scene are stored in this class until they're deleted. If I'm copying, how will I make a reference to a specific instance of a sprite?


Thanks for bearing with me for this long.

You could use references =P

Without knowing a lot more details about your architecture and the exact function calls, I have no way of knowing if you actually need the complexity of shared pointers or if simply passing things by reference is enough.  But definitely favor actual references when possible (which should be most of the time).

And by the way, since value/reference semantics is need-to-know stuff for any C++ code, you may want to read a proper book on the language sometime soon.