Is there a slicing problem with this inheritance structure?

Question

I am doing some game design, and decided that I want a data centric model... one "game data" object which gets passed from subsystem to subsystem, and knows itself how it should be drawn, how physics should operate on itself, how inputs from the user will affect it etc.

So I started out with "Listener"ish objects like "BaseRenderer" "BaseInputHandler" etc:

class BaseRenderer
{
public:
    virtual void Render(BITMAP *b) = 0;
};

class BaseInputHandler
{
public:
    virtual int TakeInputs() = 0;
};

And created a "GameData" object which inherits from these...

class GameData : public BaseRenderer, public BaseInputHandler, public BaseCalculator
{
public:
    /* Virtual Overwrites: (each child of GameData will need to overwrite these!) 
    void Render(BITMAP *b);
    int TakeInputs();
    void Calculate();*/
};

And then each subsystem has a singleton which will execute the various operations (render, take inputs, etc) on the game data...

GameData gd; // Or inherited from GameData...
Input::System().Init();
...
while(loop) {
    loop &= !(Input::System().GetInputs(&gd));
    ...
}

Is this a valid and sensible way to do inheritance? The reason I ask is because I am getting obscure runtime crashes... Not allocating any dynamic memory. Last night I got a crash from adding 2 member functions to GameData (virtual or not virtual) and then it went away when I added them slowly (first 1 non-virtual, then 1 virtual, then 2 non-virtual etc).

I read something on SO (can't remember where it was now) about inheritance and slicing. I didn't really get it, but am I doing something dangerous with my inheritance which is causing intermittent runtime bugs?

Or should I look at my timing code which is using QueryPerformanceCounter?

MinGW + allegro

I guess you mean *slicing* and not *splicing*. Slicing is explained [here](http://stackoverflow.com/questions/4403726/). I don't think that is your problem though. What you show here looks OK. You would have to describe the crashs you experience in detail. — Björn Pollex, May 18 '11 at 09:25
@Bingo, the way looks fine to me. You should have rather posted what crashes or dynamic memory problem you get. — iammilind, May 18 '11 at 09:26
Slicing, not splicing. That is probably not a risk if you pass objects by pointer or reference. It does happen if you pass by value, where a derived class might get turned into a base class. — Bo Persson, May 18 '11 at 09:27
It *could* be that you forgot to define a virtual destructor for the base classes (but maybe you just did not put it here). — Alexandre C., May 18 '11 at 09:56
@Alexandre C. I'm just using the base classes as a way to express to anybody writing a "GameData" object what functions they need to write... but I have nothing to destroy in the base class. Should I still be using virtual destructors? — Bingo, May 18 '11 at 13:13
@Space_C0wb0y I was getting a -1073741819 run time error, whatever that means. And the strange thing was I was getting it by adding a blank member function to the GameData object. So that is why I thought it had something to do with my inheritance. Now I have figured out I can get the error to occur when I bind Sleep(1000); to a key in my input handler and then press that key at run time. Maybe I should post another question... — Bingo, May 18 '11 at 13:16

score 1 · Accepted Answer · answered May 18 '11 at 09:51

Slicing occurs when you pass by value. If your base types are abstract (have pure virtual functions), slicing cannot occur; the compiler will complain instead. (Slicing occurs when an object is copied, but only the base class is copied.)

As long as you're not trying to use value semantics (pass by value, etc.), your hierarchy should be fine; most of the time, in such cases, I'll forbid copy systematically, by having everything derive from boost::noncopyable, but this isn't really necessary, as long as all of the bases are abstract.

One other special issue to pay attention to is that all explicit conversions are on pointers or references (not values), and that they use the new style casts (dynamic_cast, in general). When multiple inheritance is involved, an C-style cast can accidentally end up being a reinterpret_cast, and the code will do strange things after that.

In addition, of course, the usual issues apply: no dangling pointers, etc. (You say you have no dynamic allocation. I find this surprising if you have polymorphic types, which generally shouldn't support copy.)

I just mean that I have no dynamic allocation _yet_. My game data at the moment is just co-ordinates for a box... and these are just integer values in the class inherited from GameData on the stack in main(). It will have allocation eventually, but nothing allocation-wise is there to cause crashes... oh, and thanks for the answer :) — Bingo, May 18 '11 at 12:58

Is there a slicing problem with this inheritance structure?

1 Answers1