COM inheritence

[Ann and Jason Edmeades]

Hiya,

If you havent noticed, I'm trying to port the d3d8 code into wined3d and
make it common for use from d3d9, and this is all COM objects. I have come
across something which in theory would enable me to tidy my code simply, but
I cant see how to make it work in C.

Now I have a class, for example FRED who implements some common functions,
and all the code for it would be in fred.c. I also have a subclass, defined
called JIM, which needs to have entrypoints as per fred, plus some more, and
its code resides in jim.c. Still with me...?

Now previously, inside jim, I have duplicated all the common functions, but
I want to avoid this and just call the one definition. My plan was to change
the Vtbl to look like:
IJimVtbl Jim_Vtbl =
{
    IJimImpl_QueryInterface,
    IJimImpl_AddRef,
    IJimImpl_Release,
    IFredImpl_CommonFunc1,
    IFredImpl_CommonFunc2,
      :
    IJimImpl_UniqueFunc1 etc
}

I was also ensuring the variable definitions in the IJimImpl structure map
precisely over the IFredImpl structure, before any unique variables are
defined (I think this is a necessity for emulating subclassing in C?).

Now, obviously if the common funcs need changing I can copy in the code, and
change the vtbl to have a local override but at the moment I dont need to
(they are mostly stubs even in the d3d8 code today).

However, doing this fails to compile - It wont allow me to have a vtbl in
jim.c which includes pointers to functions which are in fred.c, even if I
have extern prototypes defined. Basically this is because array
initialization requires constant values.

However, this would seem something which is so common - ie inheritence is
used all over the place. How do people handle this? I've looked through a
few places in the code and cant see how this can be done. I could 'pretend'
by initializing the Vtbl as I create the com object and do some LoadLibrary
type dynamic addressing but I really want link time resolution not load time
resolution.

One solution would be to put the common routines in a header file, and
#include it, but code in headers or #including modules is uaually frowned
upon! I cant see any sensible way of doing this and I'd rather not do lots
of code duplication if avoidable as this common class is used in about 7
other classes!

Jason

[Robert Shearman]

Ann and Jason Edmeades wrote:
> However, this would seem something which is so common - ie inheritence is
> used all over the place. How do people handle this? I've looked through a
> few places in the code and cant see how this can be done. I could 'pretend'
> by initializing the Vtbl as I create the com object and do some LoadLibrary
> type dynamic addressing but I really want link time resolution not load time
> resolution.
>
> One solution would be to put the common routines in a header file, and
> #include it, but code in headers or #including modules is uaually frowned
> upon! I cant see any sensible way of doing this and I'd rather not do lots
> of code duplication if avoidable as this common class is used in about 7
> other classes!

Have a look at dlls/quartz/pin.h
I have emulated C++ style inheritance by creating a structure that is 
included at the start of every derived implementation and then 
constructing the vtable at compile time and linking to the base 
functions. If you wanted to do the same for d3d{8,9} and wined3d you 
would have to add each common function to the spec file.

Rob

[Ann and Jason Edmeades]

> Have a look at dlls/quartz/pin.h
> I have emulated C++ style inheritance by creating a structure that is
> included at the start of every derived implementation and then
> constructing the vtable at compile time and linking to the base
> functions. If you wanted to do the same for d3d{8,9} and wined3d you
> would have to add each common function to the spec file.

I like the solutions of putting the structures in - thats a neat
way of ensuring consistency...
> constructing the vtable at compile time and linking to the base functions.

However, I think the vtbl issue is different - Dont you get away with
constructing the vtbl because all subclasses are in the same C part, or
have I missed something?

BTW I dont want to call cross shared library for inheritance, but I
do want to call cross 'C' part in the same library, so hopefully
shouldnt need to use the spec file.

Any thoughts? If not, I'll go for forwarding functions - painful,
but not the end of the world.

Jason

[Robert Shearman]

Ann and Jason Edmeades wrote:
> > Have a look at dlls/quartz/pin.h
> > I have emulated C++ style inheritance by creating a structure that is
> > included at the start of every derived implementation and then
> > constructing the vtable at compile time and linking to the base
> > functions. If you wanted to do the same for d3d{8,9} and wined3d you
> > would have to add each common function to the spec file.
>
> I like the solutions of putting the structures in - thats a neat
> way of ensuring consistency...
> > constructing the vtable at compile time and linking to the base functions.
>
> However, I think the vtbl issue is different - Dont you get away with
> constructing the vtbl because all subclasses are in the same C part, or
> have I missed something?

They are all part of the same interface, yes.
> BTW I dont want to call cross shared library for inheritance, but I
> do want to call cross 'C' part in the same library, so hopefully
> shouldnt need to use the spec file.
>
> Any thoughts? If not, I'll go for forwarding functions - painful,
> but not the end of the world.

Forwarding functions seem to be the only maintanable way of doing this.

Rob