sf::Shape, sf::Text and sf::Sprite Baseclass suggestion

[Reborn]

Hey,
i found something which raises questions me.
And that's my storry:
I'm trying to writing a little Button-"Framework". Each of my Button-Objects can have a Graphic-Object, doesn't matter what (shape, text or maybe a sprite?).
So i looked for a common base class, the two common base class of each of that three classes are sf::Drawable and sf::Transformable.
But if i want to draw the Text, Shape or what ever in my Button-Object i have to choose (because the sf::Drawable draw function only takes sf::Drawable-References) the Drawable-Baseclass, which leads me to use dynamic_cast if i want to know where my Shape, Text or what ever is located (because i need the functions out of the sf::Transformable-Baseclass):

sf::Sprite* sp = dynamic_cast<sf::Sprite*>(m_pVisualization);
sf::Text* text = dynamic_cast<sf::Text*>(m_pVisualization);
m_bBorderIsReadyToDraw = true;
if (sp)
{
        m_pMouseOver->setPosition(sp->getPosition());
}
else if (text)
{
        m_pMouseOver->setPosition(text->getPosition());
}

So why we can't say each Transformable is Drawable too?
I think it's a applicateable statement?

Cheers

[Nexus]

dynamic_cast indicates bad design in most cases, such as here.

If you need the sf::Transformable base class, store a pointer to it. If you need the sf::Drawable interface, store a pointer to it. In case you need both, store both -- which is not ideal, but still better than dynamically casting.

And please get rid of Hungarian Notation, it makes no sense in modern C++.

[Reborn]

And please get rid of Hungarian Notation, it makes no sense in modern C++.

It's legacy code.

[Hapax]

And please get rid of Hungarian Notation, it makes no sense in modern C++.

I agree with this statement generally but I still use it for two cases: members of classes (m_) and pointers (p). Member prefix is quite obvious (I know you use one too), and the pointer prefix is because it's different from an actual instance and its usage is different.
Anyway, the code in the original post is fully notated Hungarianly, but is only members and pointers, disregarding that single boolean so, here, it's not that ugly 

[Nexus]

members of classes (m_)

Makes sense, as it doesn't refer to a type or type category, but to a scope.

the pointer prefix is because it's different from an actual instance and its usage is different.

Same for lvalue + rvalue references, smart pointers, optional objects, reference wrappers... Why should pointers get a special treatment?

That's one of the fundamental problems of HN: it's tailored to languages with a few, clearly distinct types. C++ has myriads of types and the boundaries are often blurred.

[Hapax]

the pointer prefix is because it's different from an actual instance and its usage is different.

Same for lvalue + rvalue references, smart pointers, optional objects, reference wrappers... Why should pointers get a special treatment?

Pointers end up changing the way the object is accessed ( . vs -> and *) and they are (I am) pretty clumsy so that's why I use it here: to clarify to myself.
Since, semantically, smart pointers are pointers, I would also use the same prefix for that.
I must admit, though, that it's only because they are still likely to trip me up if I don't. I tend to not use pointers very often anyway, and raw ones are (almost) always for pointing to actual objects. I'm sure that, when I'm more used to pointers etc., I may remove the prefix from my own code.

That's one of the fundamental problems of HN: it's tailored to languages with a few, clearly distinct types. C++ has myriads of types and the boundaries are often blurred.

When I was investigating HN (I was looking at Windows Programming), I was drawn in by the 'original' idea of it: the usage type, rather than the data type. Windows, as is commonly known, uses the latter, and it's really ugly. I convinced myself to avoid it but found that those two specific cases mentioned above seem to improve my understanding of it more than it hinders it.

I'll stop using the p prefix in the future; I pPromise