SFML storing drawables?

[TheHardew]

Hello!

I'd like to make games in future, so I started learning SFML. In sfml there are classes for e.g. texts, shapes and others, which all derive from sf::Drawable, so you can draw them in the same way. My question is how should I store objects of those classes? I'd like to use stack when possible (now I'm creating pong, so no heap is requaried) and be able to use methods of derived objects, like setFont() for text class. Should I use some kind of unordered map of sf::Drawable references with polymorphism and string as key or is there any better way, preferably such one, that I can use real variable names and not strings?

Thanks in advance.

[TheHardew]

Maybe I should make std::array and std::vector of something like boost.any? This way I could use all functions, for stack and heap. Maybe there's something more I can do to detect if it's from stack or heap.

[Moschops]

If they're all of type sf::Drawable, I'd go with a vector<sf::Drawable*>

[TheHardew]

Yeah, but I'd like to avoid a lot of dynamic_cast, I want to access methods of only specific classes, like sf::Text::setFont() . Plus wouldn't unordered_map be faster? And I could name my objects.

[LB]

Why do you feel you may only have one container? Just have a different container for each type of object so that C++'s type system can protect you from having to cast anything. Though really I question why you need any containers at all for a pong game...

[Zhuge]

It seems you have a bit of a conflict. You want them all in one list, which implies you want to treat them all the same. But you want to handle them by calling class specific functions. What kind of code are you planning to write that will iterate through all things that are drawable but do things specific to the actual type?

[TheHardew]

First, I agree in pong there is no need for container, I'd like to know how to store them for future games. Second I need prefferably one container for those objects, so that I can just
for (auto&& i : array) window.draw(i);. Third, sometimes you need to e.g. initialize an object, then store it for drawing, and then update with function specific only for that class, like sf::Text::setString(). Hope I stated myself clear.

[shadowmouse]

I think it's usually overkill to store them in such a way for basically any game. You usually won't have that many different classes which inherit from drawable, as you can have one class which contains many drawables and draws them all in its draw() functon, and if you do have lots of unrelated drawables, just group the drawing of them into functions like DrawStage(sf::RenderWindow&) or DrawEnemies(sf::RenderWindow&).

[Moschops]

If you've decided to group together all the drawable objects, then presumably that's for the purpose of drawing them. So you don't need to have any dynamic casts.

You have a container of sf::Drawable*, in which the "draw_yourself" function is virtual, and you simply call "draw_yourself" on every object pointed to in the container. No dynamic-casting in sight.

Because they're pointers, if you then need a container of things that can have text set on them, you could have a container of sf::thingsToSetTextOn* which point to the exact same objects as the other container does. That said, I think this design needs revisiting.

And I could name my objects.

That's nice. Do you particularly like naming things? What's the need for it? Don't solve problems you don't have.

Plus wouldn't unordered_map be faster?

For iterating through, I wouldn't have thought so. However, the odds of it mattering for your purposes are extraordinarily low. Spend your time fixing real problems, not imagined performance issues.

If your design requires you to have some extra way of keeping track of what kind of object things are, external to the objects, step back and redesign it.

[TheHardew]

Ok, thanks I'll go with what Moschops suggested, probably with priority_queue so it's easy to choose what's drawn first.