Why are get*Bounds() outside of sf::Transformable?

[silverweed]

I noticed that all SFML classes deriving from sf::Transformable separately implement getLocalBounds() and getGlobalBounds(); what is the rationale for this choice? Since Transformable provides all the various setPosition(), setOrigin() etc, wouldn't it make sense to push the get*Bounds() methods upwards in the hierarchy, at least as a virtual method?

[shadowmouse]

The problem is that sf::Transformable doesn't have a size, it's just a wrapper for sf::Transform that lets you manipulate it with simple methods and a transform is just a matrix that describes how to move a point.

[silverweed]

The problem is that sf::Transformable doesn't have a size, it's just a wrapper for sf::Transform that lets you manipulate it with simple methods and a transform is just a matrix that describes how to move a point.

Hmm, I understand. And I guess  creating a child class of Transformable from which Shape, Text and Sprite would inherit would be of dubious utility...?

It'd surely spare some code duplication, but on the other side it'd deepen the hierarchy too, so I guess it's a design choice, I can live with it

[shadowmouse]

I personally actually agree that creating a child class of Transformable would have benefits, especially if it inherited from Drawable as well which would allow easier polymorphism of anything that can be drawn and moved, which is a very common combination, however that is getting closer and closer to being the same as either Sprite or RectangleShape and it would probably end up messing up the hierarchy.

[Nexus]

There has already been such a discussion, you may find it if you search a bit...

[silverweed]

There has already been such a discussion, you may find it if you search a bit...

You mean this one, right?

Problem is, I'm not 100% sure about this:

it would even be impossible to write a generic function to do this for all the different types

...and since I couldn't reply to that thread due to necroposting, I thought opening a new thread was the way to go.

Maybe I'm just taking my problem from the wrong perspective: all I needed was a function which, given a sf::Transformable (or some class which included both sf::Sprite and sf::Text), would center it relative to some window: how can this be accomplished without knowing the size of the object?

I understand why sf::Transformable doesn't have this knowledge, but should I really write two functions doing the exact same thing to the object they're passed? Especially since the get*Bounds() methods are mostly implemented in the same way among all the classes which have them...

Or maybe there's some basilar C++ feature I'm totally overlooking which avoids creating different functions?

[Laurent]

Or maybe there's some basilar C++ feature I'm totally overlooking which avoids creating different functions?

Templates.

[Geheim]

Hey,
So I found this old post and asked OP's question myself as I was working on an interface.

From an even older post:

The two functions exist only for convenience and not all of the transformable would need those functions.

@eXpl0it3r: I assume you meant user-defined transformables by that?
Because all derived classes from SFML implement both of them, as far as I can see.

Sure, not every new class would need those, but isn't that also true for scaling, rotating, etc...?
Just because something may not be used does not mean it is useless, especially in this case and be it only for convenience.

I don't see the reason in not providing them in sf::Transformable with returning a FloatRect() by default and letting them override in derived classes if desired.
Yes it has no size -> so it has a zero area rect, right? At least it should not matter.

That being said, it is not really a problem, you can always implement them yourself ofc, I just asked out of curiousity as I only agree partly with the already provided explanations.

[Laurent]

Just because you need it, and because it could be done, doesn't mean that it is right.

From a design point of view:
- getLocalBounds() returns the untransformed size of an entity, which is defined by its geometry, ie. its area when drawn with no transform; so it should be a function of the sf::Drawable base class (see sf::VertexArray for example)
- getGlobalBounds() returns the transformed size of an entity, which means that it has to inherit from sf::Drawable (to have a local size) and sf::Transformable (to have a transform); it wouldn't mean anything in classes inheriting from sf::Transformable but not sf::Drawable
- what about a drawable class that doesn't inherit from sf::Transformable, but uses a sf::Transform directly? It would also need this getGlobalBounds() function, yet sf::Transformable is not its base

So, you see, when you think about it from a pure design point of view, it doesn't work.

[Geheim]

Oh I get it now, good points.
Thank you for clarifying and sorry for bringing this up again