Use inheritance to remove This data member

[ChrisThrasher]

Closes #222

It's reasonable to say that, for example, sfImage is an sf::Image. This "is-a" relationship is what inheritance does a very good job modeling. By using inheritance to implement CSFML types in terms of their SFML counterpart, we get code that is simpler and easier to read.

[ZXShady]

remove unnecessary ternary and static cast

[ZXShady]

readd assert and remove unnecessary static_cast and ternary

[eXpl0it3r]

Could this cause issues from pure C side or a binding using CSFML? We're only returning pointers and have typedefs, but now the fundamental type is no longer just a simple struct 🤔

[ZXShady]

the type was never a simple struct to begin with the sf Classes had non standard layout types inside it. and the typedef is to make the pointer opaque.

the user has no knowledge of what the pointer is

[ChrisThrasher]

Could this cause issues from pure C side or a binding using CSFML? We're only returning pointers and have typedefs, but now the fundamental type is no longer just a simple struct 🤔

Notice how this PR only touches the src/ directory. Users have no way to observe structs that are defined in src/. They can only see the definition of structs defined in include/. This is the reason we use opaque pointers in the interface. It gives us full freedom to implement these structs however we like.

[eXpl0it3r]

I get that, I was just wondering if there's any limit to that. We now had opaque pointers to structs, but now it's a derived type. Can this have any side effect from a C/binding point of view?

[ChrisThrasher]

No, there’s no way for users to notice anything has changed.