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 <l...@simula.no
> > <mailto:l...@simula.no>> 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
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev
