vtbl and vptr

Discussion in 'C++' started by Thomas Lenz, Dec 16, 2008.

  1. Thomas Lenz

    Thomas Lenz Guest

    Hi group,

    just curious: assuming i have a base class B with virtual functions and
    other classes derived from B:

    does this result in a vtbl / vptr's per class, or per object ?


    thanks, Thomas
     
    Thomas Lenz, Dec 16, 2008
    #1
    1. Advertising

  2. On Dec 16, 12:22 pm, Thomas Lenz <> wrote:
    > Hi group,
    >
    > just curious: assuming i have a base class B with virtual functions and
    > other classes derived from B:
    >
    > does this result in a vtbl / vptr's per class, or per object ?
    >
    > thanks, Thomas



    pointer to vtable is inserted by compiler per-object

    Regards,
    Ripunjay Tripathi
     
    Ripunjay Tripathi, Dec 16, 2008
    #2
    1. Advertising

  3. Thomas Lenz escribió:
    > Hi group,
    >
    > just curious: assuming i have a base class B with virtual functions and
    > other classes derived from B:
    >
    > does this result in a vtbl / vptr's per class, or per object ?
    >
    >
    > thanks, Thomas
    >


    The information that belongs to the class will exits per class. *If*
    this is implemented as a vtbl, there will be a vtbl per class.

    Each object needs to know the class it belongs to, and thus it will
    contain some way to do that. *If* this is implemented as a vptr, there
    will be a vptr per object.

    There may be other ways to solve virtuality problems, but always "...
    give to Caesar what is Caesar's , and to God what is God's". That is,
    information belonging to a class will exist in a per-class basis
    (similar to an static data member), information belonging to an object
    will exist within the object (similar to a non-static data member)

    Best regards,

    Zara
     
    Juan Antonio Zaratiegui Vallecillo, Dec 16, 2008
    #3
  4. Thomas Lenz

    Thomas Lenz Guest

    am Dienstag 16 Dezember 2008 09:16 schrieb Juan Antonio Zaratiegui
    Vallecillo:

    > Thomas Lenz escribió:
    >> Hi group,
    >>
    >> just curious: assuming i have a base class B with virtual functions and
    >> other classes derived from B:
    >>
    >> does this result in a vtbl / vptr's per class, or per object ?
    >>
    >>
    >> thanks, Thomas
    >>

    >
    > The information that belongs to the class will exits per class. *If*
    > this is implemented as a vtbl, there will be a vtbl per class.
    >
    > Each object needs to know the class it belongs to, and thus it will
    > contain some way to do that. *If* this is implemented as a vptr, there
    > will be a vptr per object.
    >
    > There may be other ways to solve virtuality problems, but always "...
    > give to Caesar what is Caesar's , and to God what is God's". That is,
    > information belonging to a class will exist in a per-class basis
    > (similar to an static data member), information belonging to an object
    > will exist within the object (similar to a non-static data member)
    >
    > Best regards,
    >
    > Zara


    ok, so it's one vtbl per class.

    Just to make sure i got the vptr issue right: my understanding so far is
    that vptrs point to the right virtual function, based on the "real" object
    type, not on the type of the pointer/reference that points/references to
    the object. So is there one vptr per object PER (VIRTUAL) FUNCTION? or do
    compilers (assuming they use the vptr approach) somehow manage to do this
    with just one vptr per object (only)?

    Thanks in advance,
    Thomas
     
    Thomas Lenz, Dec 16, 2008
    #4
  5. Thomas Lenz escribió:
    > am Dienstag 16 Dezember 2008 09:16 schrieb Juan Antonio Zaratiegui
    > Vallecillo:
    >
    >> Thomas Lenz escribió:
    >>> Hi group,
    >>>
    >>> just curious: assuming i have a base class B with virtual functions and
    >>> other classes derived from B:
    >>>

    <...>

    > ok, so it's one vtbl per class.
    >
    > Just to make sure i got the vptr issue right: my understanding so far is
    > that vptrs point to the right virtual function, based on the "real" object
    > type, not on the type of the pointer/reference that points/references to
    > the object. So is there one vptr per object PER (VIRTUAL) FUNCTION? or do
    > compilers (assuming they use the vptr approach) somehow manage to do this
    > with just one vptr per object (only)?
    >


    Usually, the vptr will be a pointer to the class vtbl. Such vtbl will
    contain:

    * typeid info.
    * info to resolve dynamic_cast
    * pointers to virtual functions, as overloaded for this particular
    class. Only one pointer indirection should be necessary to apply the
    function.

    Remember this info is not the only information 'virtualised', you should
    also take virtual base classes into account.

    best regards,

    Zara
     
    Juan Antonio Zaratiegui Vallecillo, Dec 16, 2008
    #5
  6. Thomas Lenz

    Rolf Magnus Guest

    Thomas Lenz wrote:

    > am Dienstag 16 Dezember 2008 09:16 schrieb Juan Antonio Zaratiegui
    > Vallecillo:
    >
    >> Thomas Lenz escribió:
    >>> Hi group,
    >>>
    >>> just curious: assuming i have a base class B with virtual functions and
    >>> other classes derived from B:
    >>>
    >>> does this result in a vtbl / vptr's per class, or per object ?
    >>>
    >>>
    >>> thanks, Thomas
    >>>

    >>
    >> The information that belongs to the class will exits per class. *If*
    >> this is implemented as a vtbl, there will be a vtbl per class.
    >>
    >> Each object needs to know the class it belongs to, and thus it will
    >> contain some way to do that. *If* this is implemented as a vptr, there
    >> will be a vptr per object.
    >>
    >> There may be other ways to solve virtuality problems, but always "...
    >> give to Caesar what is Caesar's , and to God what is God's". That is,
    >> information belonging to a class will exist in a per-class basis
    >> (similar to an static data member), information belonging to an object
    >> will exist within the object (similar to a non-static data member)
    >>
    >> Best regards,
    >>
    >> Zara

    >
    > ok, so it's one vtbl per class.
    >
    > Just to make sure i got the vptr issue right: my understanding so far is
    > that vptrs point to the right virtual function,


    No. They point to the vtable.

    > based on the "real" object type, not on the type of the pointer/reference
    > that points/references to the object. So is there one vptr per object PER
    > (VIRTUAL) FUNCTION? or do compilers (assuming they use the vptr approach)
    > somehow manage to do this with just one vptr per object (only)?


    Yes, they do. That is actually what the vtable is for. It's (mostly) a table
    of pointers to all the virtual functions in the class.
     
    Rolf Magnus, Dec 16, 2008
    #6
  7. Thomas Lenz

    Rolf Magnus Guest

    Juan Antonio Zaratiegui Vallecillo wrote:

    > Usually, the vptr will be a pointer to the class vtbl. Such vtbl will
    > contain:
    >
    > * typeid info.
    > * info to resolve dynamic_cast
    > * pointers to virtual functions, as overloaded for this particular
    > class. Only one pointer indirection should be necessary to apply the
    > function.


    Actually, it's at least 3 (might be more with multiple inheritance or
    virtual inheritance). When doing a polymorphic call, you have a pointer to
    the object to begin with. You need to dereference that to get to the vtable
    pointer. Dereferencing that brings you to the pointer to the virtual
    function to be called. And then this pointer needs to be dereferenced for
    the actual function call.
     
    Rolf Magnus, Dec 16, 2008
    #7
  8. Thomas Lenz

    Thomas Lenz Guest

    am Dienstag 16 Dezember 2008 13:37 schrieb Rolf Magnus:

    > Juan Antonio Zaratiegui Vallecillo wrote:
    >
    >> Usually, the vptr will be a pointer to the class vtbl. Such vtbl will
    >> contain:
    >>
    >> * typeid info.
    >> * info to resolve dynamic_cast
    >> * pointers to virtual functions, as overloaded for this particular
    >> class. Only one pointer indirection should be necessary to apply the
    >> function.

    >
    > Actually, it's at least 3 (might be more with multiple inheritance or
    > virtual inheritance). When doing a polymorphic call, you have a pointer to
    > the object to begin with. You need to dereference that to get to the
    > vtable pointer. Dereferencing that brings you to the pointer to the
    > virtual function to be called. And then this pointer needs to be
    > dereferenced for the actual function call.


    Thanks Juan and Rolf for this detailed explanation! It helps me a lot to get
    some deeper understanding of this virtual stuff...

    Best regards,
    Thomas
     
    Thomas Lenz, Dec 16, 2008
    #8
  9. Thomas Lenz

    red floyd Guest

    On Dec 15, 11:22 pm, Thomas Lenz <> wrote:
    > Hi group,
    >
    > just curious: assuming i have a base class B with virtual functions and
    > other classes derived from B:
    >
    > does this result in a vtbl / vptr's per class, or per object ?


    Technically, vtbl/vptr is an implementation detail. There is no
    requirement
    that a class even *have* a vtbl or vptr. I can imagine a naive (and
    not particularly
    efficient) implementation without one.
     
    red floyd, Dec 16, 2008
    #9
  10. On 16 déc, 12:16, Juan Antonio Zaratiegui Vallecillo <>
    wrote:
    > Thomas Lenz escribió:> am Dienstag 16 Dezember 2008 09:16 schrieb Juan Antonio Zaratiegui
    > > Vallecillo:

    >
    > >> Thomas Lenz escribió:
    > >>> Hi group,

    >
    > >>> just curious: assuming i have a base class B with virtual functions and
    > >>> other classes derived from B:

    >
    > <...>
    >
    > > ok, so it's one vtbl per class.

    >
    > > Just to make sure i got the vptr issue right: my understanding so far is
    > > that vptrs point to the right virtual function, based on the "real" object
    > > type, not on the type of the pointer/reference that points/references to
    > > the object. So is there one vptr per object PER (VIRTUAL) FUNCTION? or do
    > > compilers (assuming they use the vptr approach) somehow manage to do this
    > > with just one vptr per object (only)?

    >
    > Usually, the vptr will be a pointer to the class vtbl. Such vtbl will
    > contain:
    >
    > * typeid info.
    > * info to resolve dynamic_cast


    and more like MI/VI offsets (thunks) and partial ctors/dtors for
    classes inheriting from virtual base classes

    > * pointers to virtual functions, as overloaded


    I would say "as overridden" (overloading is related to types).

    > for this particular
    > class. Only one pointer indirection should be necessary to apply the
    > function.


    actually, 3 indirections and more with offsets adjustment for MI/VI.

    > Remember this info is not the only information 'virtualised', you should
    > also take virtual base classes into account.


    which leads to more vtables.

    For example assuming the two polymorphic classes B and D:

    class B { ... };
    class D : virtual B { ... };

    D should have two vtables, two ctors for each "user" defined ctor and
    instances should hold two vptrs.

    regards,

    ld.
     
    Laurent Deniau, Dec 16, 2008
    #10
  11. On 16 déc, 17:20, red floyd <> wrote:
    > On Dec 15, 11:22 pm, Thomas Lenz <> wrote:
    >
    > > Hi group,

    >
    > > just curious: assuming i have a base class B with virtual functions and
    > > other classes derived from B:

    >
    > > does this result in a vtbl / vptr's per class, or per object ?

    >
    > Technically, vtbl/vptr is an implementation detail.  There is no
    > requirement
    > that a class even *have* a vtbl or vptr.  I can imagine a naive (and
    > not particularly
    > efficient) implementation without one.


    could you describe it shortly?

    regards,

    ld.
     
    Laurent Deniau, Dec 16, 2008
    #11
  12. On 16 déc, 20:13, Paavo Helde <> wrote:
    > Laurent Deniau <> kirjutas:
    >
    >
    >
    > > On 16 déc, 17:20, red floyd <> wrote:
    > >> On Dec 15, 11:22 pm, Thomas Lenz <> wrote:

    >
    > >> > Hi group,

    >
    > >> > just curious: assuming i have a base class B with virtual functions
    > >> > and other classes derived from B:

    >
    > >> > does this result in a vtbl / vptr's per class, or per object ?

    >
    > >> Technically, vtbl/vptr is an implementation detail.  There is no
    > >> requirement
    > >> that a class even *have* a vtbl or vptr.  I can imagine a naive (and
    > >> not particularly
    > >> efficient) implementation without one.

    >
    > > could you describe it shortly?

    >
    > When creating objects by 'new',


    what do you mean by 'new', could you give details about the steps?

    > the pointer is registered in a global
    > lookup container corresponding to the actual class. All cases of virtual
    > dispatch will be implemented as ordinary functions according to the
    > pseudo-code:
    >
    > int virtual_member_f1(void* this_ptr, int arg1) {
    >         if (global_register_for_triangle.contains(this_ptr)) {
    >             return triangle::f1(this_ptr, arg1);
    >         } else if (global_register_for_cube.contains(this_ptr)) {
    >                 return cube::f1(this_ptr, arg1);
    >         } // etc...


    This is not conformant. All virtual methods are "always" virtual in
    your case. How do you manage virtual destructors and virtual member
    functions called within constructors?

    > No vtables, no vptr-s. Adding new classes in dynamically loaded libraries
    > is left as an exercise to the reader.


    I let as an exercise to the poster to understand why this approach
    cannot work.

    a+, ld.
     
    Laurent Deniau, Dec 16, 2008
    #12
  13. On 2008-12-16 20:13, Paavo Helde wrote:
    > Laurent Deniau <> kirjutas:
    >
    >> On 16 dé–, 17:20, red floyd <> wrote:
    >>> On Dec 15, 11:22爌m, Thomas Lenz <> wrote:
    >>>
    >>> > Hi group,
    >>>
    >>> > just curious: assuming i have a base class B with virtual functions
    >>> > and other classes derived from B:
    >>>
    >>> > does this result in a vtbl / vptr's per class, or per object ?
    >>>
    >>> Technically, vtbl/vptr is an implementation detail. 燭here is no
    >>> requirement
    >>> that a class even *have* a vtbl or vptr. 營 can imagine a naive (and
    >>> not particularly
    >>> efficient) implementation without one.

    >>
    >> could you describe it shortly?

    >
    > When creating objects by 'new', the pointer is registered in a global
    > lookup container corresponding to the actual class.


    Another, probably more efficient implementation would be to allocate all
    classes of the same type from the same "region" of memory (think block
    allocator) and when accessing a virtual function you mask out the least
    significant bits of the object's address which gives the address to the
    "region head" containing the vtable.

    --
    Erik Wikström
     
    Erik Wikström, Dec 16, 2008
    #13
  14. Thomas Lenz

    Rolf Magnus Guest

    Laurent Deniau wrote:

    >> >> Technically, vtbl/vptr is an implementation detail. There is no
    >> >> requirement
    >> >> that a class even *have* a vtbl or vptr. I can imagine a naive (and
    >> >> not particularly
    >> >> efficient) implementation without one.

    >>
    >> > could you describe it shortly?

    >>
    >> When creating objects by 'new',

    >
    > what do you mean by 'new', could you give details about the steps?


    Uhm? Never heard of dynamic memory allocation in C++?

    >> the pointer is registered in a global
    >> lookup container corresponding to the actual class. All cases of virtual
    >> dispatch will be implemented as ordinary functions according to the
    >> pseudo-code:
    >>
    >> int virtual_member_f1(void* this_ptr, int arg1) {
    >> if (global_register_for_triangle.contains(this_ptr)) {
    >> return triangle::f1(this_ptr, arg1);
    >> } else if (global_register_for_cube.contains(this_ptr)) {
    >> return cube::f1(this_ptr, arg1);
    >> } // etc...

    >
    > This is not conformant. All virtual methods are "always" virtual in
    > your case.


    What is not conforming about that?

    > How do you manage virtual destructors and virtual member
    > functions called within constructors?


    The same?
     
    Rolf Magnus, Dec 16, 2008
    #14
  15. Thomas Lenz

    red floyd Guest

    On Dec 16, 9:04 am, Laurent Deniau <> wrote:
    > On 16 déc, 17:20, red floyd <> wrote:
    > > Technically, vtbl/vptr is an implementation detail.  There is no
    > > requirement
    > > that a class even *have* a vtbl or vptr.  I can imagine a naive (and
    > > not particularly
    > > efficient) implementation without one.

    >
    > could you describe it shortly?


    Sure. Each virtual function is implemented as a function pointer
    inside the class object. Note that they would not have to be
    contiguous, hence, no "vtbl". Since there's no vtbl, no vptr.

    e.g.:

    struct S
    {
    int x;
    virtual void f();
    int y;
    virtual void g();
    };

    would have the same layout as the C struct:


    struct S
    {
    int x;
    void (*f)();
    int y;
    void (*g)();
    };

    Again, no vtbl, because the pointers to virtual functions aren't
    contiguous. No vtbl => no vptr.
     
    red floyd, Dec 16, 2008
    #15
  16. Thomas Lenz

    James Kanze Guest

    On Dec 16, 8:13 pm, Paavo Helde <> wrote:
    > Laurent Deniau <> kirjutas:
    > > On 16 déc, 17:20, red floyd <> wrote:
    > >> On Dec 15, 11:22 pm, Thomas Lenz <> wrote:


    > >> > just curious: assuming i have a base class B with virtual
    > >> > functions and other classes derived from B:


    > >> > does this result in a vtbl / vptr's per class, or per object ?


    > >> Technically, vtbl/vptr is an implementation detail. There
    > >> is no requirement that a class even *have* a vtbl or vptr.
    > >> I can imagine a naive (and not particularly efficient)
    > >> implementation without one.


    > > could you describe it shortly?


    > When creating objects by 'new', the pointer is registered in a
    > global lookup container corresponding to the actual class.


    'new' has nothing to do with it. The compiler generates extra
    code in the constructor to insert the this pointer(s) into a map
    (as keys).

    > All cases of virtual dispatch will be implemented as ordinary
    > functions according to the pseudo-code:


    > int virtual_member_f1(void* this_ptr, int arg1) {
    > if (global_register_for_triangle.contains(this_ptr)) {
    > return triangle::f1(this_ptr, arg1);
    > } else if (global_register_for_cube.contains(this_ptr)) {
    > return cube::f1(this_ptr, arg1);
    > } // etc...


    > No vtables, no vptr-s. Adding new classes in dynamically
    > loaded libraries is left as an exercise to the reader.


    I doubt that that could be made to work. But a map from the
    pair <function name, this> to the pair <this fixup, function
    address> certainly could.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Dec 16, 2008
    #16
  17. Thomas Lenz

    James Kanze Guest

    On Dec 16, 8:53 pm, Laurent Deniau <> wrote:
    > On 16 déc, 20:13, Paavo Helde <> wrote:
    > > Laurent Deniau <> kirjutas:


    [...]
    > > the pointer is registered in a global lookup container
    > > corresponding to the actual class. All cases of virtual
    > > dispatch will be implemented as ordinary functions according
    > > to the pseudo-code:


    > > int virtual_member_f1(void* this_ptr, int arg1) {
    > > if (global_register_for_triangle.contains(this_ptr)) {
    > > return triangle::f1(this_ptr, arg1);
    > > } else if (global_register_for_cube.contains(this_ptr)) {
    > > return cube::f1(this_ptr, arg1);
    > > } // etc...


    > This is not conformant. All virtual methods are "always"
    > virtual in your case. How do you manage virtual destructors
    > and virtual member functions called within constructors?


    The compiler generates code in the constructors and destructors
    to deregister from one registry, and re-register in another.
    Just as it generates code today to change the vptr.

    The reason this can't be made to work, as is, is because it
    implies that the compiler know all of the derived classes at one
    point. (Theoretically, I guess, the linker could generate these
    functions, but practically, I don't think that's reasonable.)

    > > No vtables, no vptr-s. Adding new classes in dynamically
    > > loaded libraries is left as an exercise to the reader.


    > I let as an exercise to the poster to understand why this
    > approach cannot work.


    If you drop separate compilation, it could.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Dec 16, 2008
    #17
  18. Thomas Lenz

    James Kanze Guest

    On Dec 16, 9:28 pm, Erik Wikström <> wrote:
    > On 2008-12-16 20:13, Paavo Helde wrote:
    > > Laurent Deniau <> kirjutas:


    > >> On 16 dé–, 17:20, red floyd <> wrote:
    > >>> On Dec 15, 11:22爌m, Thomas Lenz <> wrote:


    > >>> > just curious: assuming i have a base class B with
    > >>> > virtual functions and other classes derived from B:


    > >>> > does this result in a vtbl / vptr's per class, or per object ?


    > >>> Technically, vtbl/vptr is an implementation detail. There
    > >>> is no requirement that a class even *have* a vtbl or vptr.
    > >>> I imagine a naive (and not particularly efficient)
    > >>> implementation without one.


    > >> could you describe it shortly?


    > > When creating objects by 'new', the pointer is registered in
    > > a global lookup container corresponding to the actual class.


    > Another, probably more efficient implementation would be to
    > allocate all classes of the same type from the same "region"
    > of memory (think block allocator) and when accessing a virtual
    > function you mask out the least significant bits of the
    > object's address which gives the address to the "region head"
    > containing the vtable.


    Rather difficult for objects with auto or static lifetime, no?
    Of course, you could probably recognize those from the address
    too, and use Paavo's suggestion as a back-up method.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Dec 16, 2008
    #18
  19. On 17 déc, 00:19, James Kanze <> wrote:
    > On Dec 16, 8:53 pm, Laurent Deniau <> wrote:
    >
    > > On 16 déc, 20:13, Paavo Helde <> wrote:
    > > > Laurent Deniau <> kirjutas:

    >
    >     [...]
    >
    > > > the pointer is registered in a global lookup container
    > > > corresponding to the actual class. All cases of virtual
    > > > dispatch will be implemented as ordinary functions according
    > > > to the pseudo-code:
    > > > int virtual_member_f1(void* this_ptr, int arg1) {
    > > >         if (global_register_for_triangle.contains(this_ptr)) {
    > > >             return triangle::f1(this_ptr, arg1);
    > > >         } else if (global_register_for_cube.contains(this_ptr)) {
    > > >                 return cube::f1(this_ptr, arg1);
    > > >         } // etc...

    > > This is not conformant. All virtual methods are "always"
    > > virtual in your case. How do you manage virtual destructors
    > > and virtual member functions called within constructors?

    >
    > The compiler generates code in the constructors and destructors
    > to deregister from one registry, and re-register in another.
    > Just as it generates code today to change the vptr.


    James, you are underestimating the complexity of the virtual
    inheritance ;-)

    assuming the following polymorphic types (with virtual member
    functions) all holding a long integer of the same name (e.g. A has an
    'a', B has an 'b', etc):

    struct A { ... };
    struct B { ... };
    struct AB : virtual A, virtual B { ... };
    struct BA : virtual B, virtual A { ... };
    struct ABBA : AB, BA { ... };

    here is what the ABBA ctor and its partial ctor_ must do (the dtor and
    dtor_ do nearly the same in the reverse order):

    // C++
    ABBA(long a, long b, long ab, long ba, long abba_) :
    A(a), B(b), AB(a,b,ab), BA(a,b,ba), abba(abba_) {}

    // C equivalent
    void ABBA_ctor(register ABBA* const this,
    long a, long b, long ab, long ba, long abba)
    {
    A_ctor(BASE(this,A), a); /* compiler + user */
    B_ctor(BASE(this,B), b); /* compiler + user */
    AB_ctor_((AB*)this, ABBA_vtt, a, b, ab); /* compiler + user */
    BA_ctor_(BASE(this,BA), ABBA_vtt+3, a, b, ba); /* compiler + user */
    this->vptr = ABBA_vtbl; /* compiler */
    this->BA_vptr = ABBA_BA_vtbl; /* compiler */
    this->A_vptr = ABBA_A_vtbl; /* compiler */
    this->B_vptr = ABBA_B_vtbl; /* compiler */
    this->abba = abba; /* user */
    }

    // C equivalent, partial ctor, vtt is a table of vtbl
    void ABBA_ctor_(register ABBA* const this, const VTABLE* const vtt[],
    long a, long b, long ab, long ba, long abba)
    {
    AB_ctor_((AB*)this, vtt+4, a, b, ab);
    BA_ctor_(BASE(this,BA), vtt+7, a, b, ba);
    this->vptr = vtt[0];
    this->BA_vptr = vtt[1];
    VBASE(this,ABBA_A)->vptr = vtt[2];
    VBASE(this,ABBA_B)->vptr = vtt[3];
    this->abba = abba;
    }

    This code is part of my (unfinish) paper on the C++ object model from
    2004. The code is completed, compiles and works and demonstrate how
    all the machinery works. It can be found there

    http://cern.ch/laurent.deniau/oopc.html#CPPObjModel

    it is based on the paper of Nathan Sidwell, ACCU 2003. The cited
    "Inside the C++ Object Model"
    from Stanley B. Lippman is obsolete (does not reflect models currently
    used) but still very didactic.

    > The reason this can't be made to work, as is, is because it
    > implies that the compiler know all of the derived classes at one
    > point.  (Theoretically, I guess, the linker could generate these
    > functions, but practically, I don't think that's reasonable.)


    Right. This is why I say that it cannot work.

    > > > No vtables, no vptr-s. Adding new classes in dynamically
    > > > loaded libraries is left as an exercise to the reader.

    > > I let as an exercise to the poster to understand why this
    > > approach cannot work.

    >
    > If you drop separate compilation, it could.


    Of course. All program analysis can do everything, but then you don't
    need polymorphism at all ;-)

    a+, ld.
     
    Laurent Deniau, Dec 17, 2008
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Veeru
    Replies:
    7
    Views:
    1,263
    tragomaskhalos
    Sep 15, 2006
  2. pai
    Replies:
    4
    Views:
    964
  3. Subhransu Sahoo

    A basic doubt on VPTR and VTABLES

    Subhransu Sahoo, Nov 7, 2006, in forum: C++
    Replies:
    4
    Views:
    362
  4. VPTR and VTABLE

    , Dec 1, 2009, in forum: C++
    Replies:
    9
    Views:
    4,199
    James Kanze
    Dec 2, 2009
  5. Serve Laurijssen

    vtbl inheritance

    Serve Laurijssen, Jan 30, 2011, in forum: C++
    Replies:
    23
    Views:
    1,010
Loading...

Share This Page