Re: [GD-General] Multiple Inheritance and RTTI

[brian s. <pud...@po...>]

I would 3rd the recommendation for Inside COM, and point out that there 
are some other tricks you can pull off with a QueryInterface approach 
that can't be achieved with dynamic_cast (or rather, I don't see how to 
achieve them).  

The most useful one to my mind is aggregation.  An object can be built 
as a collection of other objects (has-a rather than is-a), and those 
objects can delegate all QI calls to their parent.  By doing this, given 
one interface pointer from the parent object, you can cross-cast to 
another interface, even though those 2 interfaces are implemented in 
separate classes.  A rotten example:

class COneTwo : public IUnknown {
    IOne * mOne;
    ITwo * mTwo;
    ...
}

With aggregation, one can get an IOne interface off the COneTwo object, 
and then get an ITwo interface off that IOne interface.  But the actual 
implementations of IOne and ITwo are in completely different classes.

When you picture being able to bolt on orthogonal behavior to objects, 
like combining IDebugRender with objects that implement other 
interfaces, this gets more interesting.  No more do you have to put 
IDebugRender near the top of your inheritance tree; you just give an 
implementation to objects that need it, without modifying the 
implementation of the other interfaces that the object supports.  Groovy!

ATL Internals is a great book to read if you want to set up your COM 
system to support this and other such exotica (tear-off interfaces, etc).

Question: there were references to code bloat produced by RTTI.  Is that 
really a big issue?  It's just some bytes added per vtable - I'm 
wondering if anyone's measured it to come up with a more exact number 
than that.  My gut feeling is that it wouldn't be that significant, but 
I'm wondering if my gut is lying...or maybe the feeling in my gut is 
really coming from the Mexican food I had at lunch...

--brian

Noel Llopis wrote:

>I found the book Inside COM to be extremely enlightening. The author
>goes step by step developing a COM-like approach (until it becomes
>full-blown COM), which is pretty much what you want to see.
>
>You can check out one of my articles in Game Programming Gems 2. It
>talks about exactly this topic, and it provides some sample code
>(although it seems you have figured it all of it by yourself already).
>
>Finally, at the danger of blowing my own trumpet too much, I have a
>whole chapter dedicated to this in my upcoming book "C++ for Game
>Programmers" (http://www.amazon.com/exec/obidos/ASIN/1584502274)
>
>
>--Noel
>ll...@co...
>
>  
>