dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Nov 09, 2009 at 03:45:00PM +0100, Jed Brown wrote:
> Matthew Knepley wrote:
>
> > I believe that the cast causes it to offset into the object structure.
> > Everyone still points to the same virtual function table
>
> This example has no vtable, but if it did, both the struct and the
> corresponding vtable would be concatenated from A and B.  C would have a
> layout equivalent to the C struct:
>
> struct C {
>   void *vptr_A;
>   int avar;
>   void *vptr_B;
>   int bvar;
> };
>
> with vtable
>
> struct C_vtable {
>   void (*amethod)();
>   void (*cmethod)();
>   void (*reserved)();       /* I don't know what this space is for */
>   void (*typeinfo_for_C)();
>   void (*bmethod)();
> };
>
> C::vptr_A points to the beginning of C_vtable while C::vptr_B points to
> the offset.  (This is my recollection from vtable debugging a while ago,
> I'm sure these layout details are somewhat gcc-specific, but I don't
> think anyone does multiple inheritance substantially differently.)
> > On Mon, Nov 9, 2009 at 7:12 AM, Anders Logg <logg@xxxxxxxxx
> > <mailto:logg@xxxxxxxxx>> wrote:
> >
> >     I'm struggling with some problems in the implementation of automatic
> >     update/interpolation during mesh refinement.
> >
> >     I've narrowed one of the problems down to the following simple
> >     example. Say that a class C inherits from both A and B (which both
> >     have member variables - this is important). Then I would expect an
> >     object c of class C to have the same address/pointer as seen from all
> >     three classes.
>
> It could not possibly work this way because B must be able to function
> correctly with no knowledge of A and C.

I don't understand why that would not work. It looks to me like it's
just some trick to simplify the cast from a C to a B, and that cast is
handled by an offset in the struct.

--
Anders

Attachment: signature.asc
Description: Digital signature