0

Currently I have two classes, Drawable and Transformable and things like Actors inherit both of these, the problem is when drawing objects to the screen I iterate through a vector of Drawables which do not have the getPosition() function included in Transformable. Adding a virtual getPosition() to Drawable solves this but then creates the problem of ambiguous calls to the function elsewhere. So can I have Drawable inherit Transformable and Actor inherit Drawable and get the same result as if it were inheriting both classes?

EDIT: Drawables aren't all actors, some are sprites (game objects), primitive shapes, etc. Actually the only reason I need the getPosition() in the draw loop is because in order to fake depth, I loop through the vector to go from 0 Y coordinate to the bottom of the screen, objects higher up on the screen get drawn first and are then behind objects closer to the "front". I didn't write the Drawable/Transformable classes and I'd prefer to not have to completely change them in order to satisfy one function call in one instance. The only time this is a problem is when I reference the vector of Drawables. It doesn't quite make sense to me why this was designed the way it was because everything that uses the drawable class also inherits the transformable class, so they should just be one but they aren't.

My question is whether this:

class foo {}
class bar{}
class foobar : public foo, public bar {}

is the same as this

class foo {}
class bar : public foo {}
class foobar : public bar {}

Can an object inherit the public and protected members of the class their parent inherits?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Mike
  • 587
  • 1
  • 6
  • 11
  • You've gone a little over-the-top on trying to map properties to types. Why not a vector of Actors? As you've discovered, knowing that something "is drawable" is not the same as knowing "how to draw it". Actually, in this case, I'd say that something should have a position even if it's not transformable. – Lightness Races in Orbit Oct 27 '13 at 13:37
  • 3
    why not show some code? – Ed Heal Oct 27 '13 at 13:37
  • No - Try drawing a diagram – Ed Heal Oct 27 '13 at 13:51

2 Answers2

0

In this case, the design that I would choose is removing the Transformable class, and moving the positional attributes and member functions to the Drawable class. Something that is 'drawable' needs to be drawn somewhere, and therefore requires a position, regardless of it can move or not.

Can an object inherit the public and protected members of the class their parent inherits?

Short and sweet: Yes. (Only if the inheritance is public or protected)

See this for more info on types of inheritance.

Community
  • 1
  • 1
azz
  • 5,852
  • 3
  • 30
  • 58
  • Also recommend taking a look at [this answer](http://stackoverflow.com/a/1372858/1280997) too. – azz Oct 27 '13 at 14:02
0

Consider if an object which is not drawable would ever be transformed in the first place. Why move something that never gets seen.

Also, shouldn't getPosition (and presumably setPosition) actually be part of something that is drawable? How do you know where to draw it otherwise.

I strongly suggest reconsidering your class structure carefully, combine functionality which is common, don't have millions of unnecessary interfaces just because you can.

Ashigore
  • 4,618
  • 1
  • 19
  • 39
  • I agree but I'm modifying an open source library to work with what I want to do, changing the entire structure of the library at this point would be far more then I want to take on. The draw function actually is a virtual function in drawable, it's implemented in Drawables friend class RenderTarget, which uses a pointer to the vertices of the object and the number of vertices in the array to draw primitives to a specific renderstate. It's convoluted but it works and I didn't write it so I'd prefer not to change it. – Mike Oct 27 '13 at 13:55