Drawable and Transformable class

[kubawal]

I think all drawable and transformable things could have the same parent class.
For example:

namespace sf
{
class Object
: sf::Drawable, sf::Transformable
{
};

// and all drawable and transformable classes derives it
// for exmaple:
class Sprite
: sf::Object
{
//...
};
 

I came up with this idea when i written SFML and Box2d framework, when I needed to write method returning drawable object which i can set it position.

[zsbzsb]

And how would this help? 

returning drawable object which i can set it position.

Just return a sf::Transformable type... Or use a template 

Changing the entire library just because it doesn't necessarily match your design is not the best idea. Maybe you should consider improving on your overall design. 

[kubawal]

And how i can draw it?

win.draw(*((Drawable*)transformablePtr));

This is a very bad code, because i don't know whether transformablePtr is Drawable.

[zsbzsb]

Separate your update code from your drawing code... And even better make your own object inherit from sf::Drawable

[eXpl0it3r]

It would've been better to include the reason for such a request in the first post.

So here it is: It's cumbersome to have a container of sf::Transformable, because it requires additional tracking and casting to access the sf::Drawable functionalities. Or the other way around, it's cumbersome to have a container of sf::Drawable, because it requires additional tracking and casting to access the sf::Transformable functionalities. This is not issue for custom classes, but when it comes to reusing SFML's classes it won't work.
A class that aids as base class for Sprites and Shapes and combines Drawable and Transformable would make possible again to mix them all.

This was just to clarify what's going on here, since the OP didn't include the reasoning.

If you use anything like that in your code, make sure to give it a different name "object" is about as generic as you could ever get and nobody will understand what it actually is.

While I certainly see the issue, I'd say that your design might be flawed. I can't fully judge, since I didn't see your code. I generally wouldn't go with one container hold all objects that can be drawn or transformed, instead I'd most likely go with some sort of Entity class that has its own public API, that gets used inside the game, while the Entity itself holds a sprite/vertex array/shape and forwards the calls of its API to the inner drawable.
That way, it's easy to just create a container of Entity and you don't have to bother with Drawables and Transformables. But it really depends on what you do.