Is the vptr at the beginning of an object?

Discussion in 'C++' started by DaveB, Apr 2, 2010.

  1. DaveB

    DaveB Guest

    In practice, across most compilers, is the vptr at offset 0 of a class
    object? I've found some posts that say GCC puts it at the end, but they
    were very old posts and I don't use it now so can't test it.
     
    DaveB, Apr 2, 2010
    #1
    1. Advertising

  2. DaveB

    James Kanze Guest

    On Apr 2, 9:56 am, "DaveB" <> wrote:
    > In practice, across most compilers, is the vptr at offset 0 of
    > a class object? I've found some posts that say GCC puts it at
    > the end, but they were very old posts and I don't use it now
    > so can't test it.


    Who cares? What does it matter where the vptr is placed? (And
    of course, many objects have more than one vptr, and not all of
    them can be at offset 0.)

    --
    James Kanze
     
    James Kanze, Apr 2, 2010
    #2
    1. Advertising

  3. DaveB

    Paul N Guest

    On 2 Apr, 11:07, James Kanze <> wrote:
    > On Apr 2, 9:56 am, "DaveB" <> wrote:
    >
    > > In practice, across most compilers, is the vptr at offset 0 of
    > > a class object? I've found some posts that say GCC puts it at
    > > the end, but they were very old posts and I don't use it now
    > > so can't test it.

    >
    > Who cares?  What does it matter where the vptr is placed?  (And
    > of course, many objects have more than one vptr, and not all of
    > them can be at offset 0.)


    Just out of curiosity, I thought the compiler was obliged to put the
    first member at offset zero? If so (and it could well be I'm wrong
    here...) then it must put the vptr (assuming there is one) somewhere
    else?
     
    Paul N, Apr 2, 2010
    #3
  4. * Paul N:
    > On 2 Apr, 11:07, James Kanze <> wrote:
    >> On Apr 2, 9:56 am, "DaveB" <> wrote:
    >>
    >>> In practice, across most compilers, is the vptr at offset 0 of
    >>> a class object? I've found some posts that say GCC puts it at
    >>> the end, but they were very old posts and I don't use it now
    >>> so can't test it.

    >> Who cares? What does it matter where the vptr is placed? (And
    >> of course, many objects have more than one vptr, and not all of
    >> them can be at offset 0.)

    >
    > Just out of curiosity, I thought the compiler was obliged to put the
    > first member at offset zero?


    Only for a POD. For a POD it's guaranteed by reinterpret_cast to suitable type
    yielding a pointer to the first member (and vice versa).


    > If so (and it could well be I'm wrong
    > here...) then it must put the vptr (assuming there is one) somewhere
    > else?


    When the first data member is at offset 0 a vptr, if the implementation uses
    that scheme (but all do), must be put somewhere else, yes.

    Generally this is only relevant when considering binary layout compatibility.

    However, the language supports compilers that put a vpointer at offset 0, e.g.
    when introducing a virtual member function in a derived class, because given a
    pointer to some class type object a static_cast up or down an inheritance chain
    can change the pointer value as given by a conversion to void*.


    Cheers & hth.,


    - Alf
     
    Alf P. Steinbach, Apr 2, 2010
    #4
  5. DaveB

    DaveB Guest

    James Kanze wrote:
    > On Apr 2, 9:56 am, "DaveB" <> wrote:
    >> In practice, across most compilers, is the vptr at offset 0 of
    >> a class object? I've found some posts that say GCC puts it at
    >> the end, but they were very old posts and I don't use it now
    >> so can't test it.

    >
    > Who cares? What does it matter where the vptr is placed? (And
    > of course, many objects have more than one vptr, and not all of
    > them can be at offset 0.)


    If you couldn't answer the question asked, you shouldn't have bothered
    posting!
     
    DaveB, Apr 2, 2010
    #5
  6. DaveB

    Ian Collins Guest

    On 04/ 3/10 12:16 AM, DaveB wrote:
    > James Kanze wrote:
    >> On Apr 2, 9:56 am, "DaveB"<> wrote:
    >>> In practice, across most compilers, is the vptr at offset 0 of
    >>> a class object? I've found some posts that say GCC puts it at
    >>> the end, but they were very old posts and I don't use it now
    >>> so can't test it.

    >>
    >> Who cares? What does it matter where the vptr is placed? (And
    >> of course, many objects have more than one vptr, and not all of
    >> them can be at offset 0.)

    >
    > If you couldn't answer the question asked, you shouldn't have bothered
    > posting!


    He did answer the question!

    --
    Ian Collins
     
    Ian Collins, Apr 2, 2010
    #6
  7. DaveB

    DaveB Guest

    Ian Collins wrote:
    > On 04/ 3/10 12:16 AM, DaveB wrote:
    >> James Kanze wrote:
    >>> On Apr 2, 9:56 am, "DaveB"<> wrote:
    >>>> In practice, across most compilers, is the vptr at offset 0 of
    >>>> a class object? I've found some posts that say GCC puts it at
    >>>> the end, but they were very old posts and I don't use it now
    >>>> so can't test it.
    >>>
    >>> Who cares? What does it matter where the vptr is placed? (And
    >>> of course, many objects have more than one vptr, and not all of
    >>> them can be at offset 0.)

    >>
    >> If you couldn't answer the question asked, you shouldn't have
    >> bothered posting!

    >
    > He did answer the question!


    He can speak for himself!
     
    DaveB, Apr 2, 2010
    #7
  8. DaveB

    James Kanze Guest

    On Apr 2, 12:16 pm, "DaveB" <> wrote:
    > James Kanze wrote:
    > > On Apr 2, 9:56 am, "DaveB" <> wrote:
    > >> In practice, across most compilers, is the vptr at offset 0
    > >> of a class object? I've found some posts that say GCC puts
    > >> it at the end, but they were very old posts and I don't use
    > >> it now so can't test it.


    > > Who cares? What does it matter where the vptr is placed?
    > > (And of course, many objects have more than one vptr, and
    > > not all of them can be at offset 0.)


    > If you couldn't answer the question asked, you shouldn't have
    > bothered posting!


    I gave the only relevant answer. It doesn't matter where the
    compiler puts the vptr. It could put it anywhere, and change
    where it puts it from one version to the next, or even with a
    change in the compilation options. And of course, the question
    doesn't even make sense, since objects may have more than one
    vptr.

    --
    James Kanze
     
    James Kanze, Apr 2, 2010
    #8
  9. DaveB

    red floyd Guest

    On Apr 2, 8:25 am, Branimir Maksimovic <> wrote:
    > On Fri, 2 Apr 2010 08:02:20 -0700 (PDT)
    >
    >
    >
    > James Kanze <> wrote:
    > > On Apr 2, 12:16 pm, "DaveB" <> wrote:
    > > > James Kanze wrote:
    > > > > On Apr 2, 9:56 am, "DaveB" <> wrote:
    > > > >> In practice, across most compilers, is the vptr at offset 0
    > > > >> of a class object? I've found some posts that say GCC puts
    > > > >> it at the end, but they were very old posts and I don't use
    > > > >> it now so can't test it.

    >
    > > > > Who cares?  What does it matter where the vptr is placed?
    > > > > (And of course, many objects have more than one vptr, and
    > > > > not all of them can be at offset 0.)

    >
    > > > If you couldn't answer the question asked, you shouldn't have
    > > > bothered posting!

    >
    > > I gave the only relevant answer.  It doesn't matter where the
    > > compiler puts the vptr.  It could put it anywhere, and change
    > > where it puts it from one version to the next, or even with a
    > > change in the compilation options.  And of course, the question
    > > doesn't even make sense, since objects may have more than one
    > > vptr.

    >
    > > --
    > > James Kanze

    >
    > Is there possibility for implementation not to use vptr
    > at all? Eg implementation that would dispatch on 'if's'
    > based on type? Eg where indirect function calls are expensive?
    >


    I can imagine a vptr-less implementation, where each virtual function
    is implemented as a pointer within each object, rather than a vtbl
    implementation, where such pointers are a per-class thing. So to talk
    about the vptr at all is nonsense, especially since it isn't mandated.

    If you want to discuss vptr specifics, you'd almost by definition have
    to do it in a platform specific forum. And, as James has mentioned,
    in the case of MI and a vptr implementation, you'll probably have
    multiple
    vptrs.
     
    red floyd, Apr 2, 2010
    #9
  10. DaveB

    DaveB Guest

    "James Kanze" <> wrote in message
    news:...
    > On Apr 2, 12:16 pm, "DaveB" <> wrote:
    >> James Kanze wrote:
    >> > On Apr 2, 9:56 am, "DaveB" <> wrote:
    >> >> In practice, across most compilers, is the vptr at offset 0
    >> >> of a class object? I've found some posts that say GCC puts
    >> >> it at the end, but they were very old posts and I don't use
    >> >> it now so can't test it.

    >
    >> > Who cares? What does it matter where the vptr is placed?
    >> > (And of course, many objects have more than one vptr, and
    >> > not all of them can be at offset 0.)

    >
    >> If you couldn't answer the question asked, you shouldn't have
    >> bothered posting!

    >
    > I gave the only relevant answer. It doesn't matter where the
    > compiler puts the vptr. It could put it anywhere, and change
    > where it puts it from one version to the next, or even with a
    > change in the compilation options. And of course, the question
    > doesn't even make sense, since objects may have more than one
    > vptr.
    >


    Techno gibberish. I asked about common practice, not hypothetical theory,
    and it doesn't take anyone with one ioda of intuition to assume that I
    was talking about the simple case. Use of this forum to spout
    technobabble at any/every opportunity, is annoying at best. (If you can't
    help it because you are a nerd, then I apologize for not being cognitive
    of the affliction, and hope you get the help you need).
     
    DaveB, Apr 2, 2010
    #10
  11. DaveB

    red floyd Guest

    On 4/2/2010 2:12 PM, DaveB wrote:
    > [insult to a member of the Committee redacted]


    *PLONK*
     
    red floyd, Apr 3, 2010
    #11
  12. * red floyd:
    > On 4/2/2010 2:12 PM, DaveB wrote:
    >> [insult to a member of the Committee redacted]

    >
    > *PLONK*


    Well, there was a bit of insult, true.

    On the other hand, I fail to see what James' state as a member of the
    standardization committee has to do with anything. I.e. your response is quite
    perplexing. It's like "Insult to a human being WITH NOSE redacted".

    Appeal to authority (have nose, member of this or that) is a fallacy just as
    much as an insult. E.g., by this fallacious measure we'd have to stop discussing
    Herbert Schildt's books. Not that I'm comparing you or James to Herbert; that
    conclusion would be yet another fallacy (the name of which I've forgotten).


    Cheers & hth.,

    - Alf

    PS: "plonk" is the sound of some serious shit being flushed down the toilet. In
    Usenet jargon that means that an otherwise somewhat respected person has been
    added to your kill-list. The sound of light-weight shit is just "plink".
     
    Alf P. Steinbach, Apr 3, 2010
    #12
  13. DaveB

    James Kanze Guest

    On Apr 2, 4:25 pm, Branimir Maksimovic <> wrote:
    > On Fri, 2 Apr 2010 08:02:20 -0700 (PDT)
    > James Kanze <> wrote:
    > > On Apr 2, 12:16 pm, "DaveB" <> wrote:


    [...]
    > Is there possibility for implementation not to use vptr
    > at all?


    In theory, at least. As someone (I think it was Alf), all
    compilers do use a vptr in practice.

    > Eg implementation that would dispatch on 'if's' based on type?
    > Eg where indirect function calls are expensive?


    The if's would have to be generated at link time, when the
    compiler knew all possible types. In practice, some compilers
    do do this, but only in time critical loops, as determined by
    the profiler. They still maintain the vptr for less critical
    sections. In fact, they normally only use the if in cases
    where one function is largely predominant, testing whether the
    call resolves to that one function, and using the vptr mechanism
    if not. And it is normally associated with inlining the most
    frequent function, to maximize the associated gains.

    --
    James Kanze
     
    James Kanze, Apr 3, 2010
    #13
  14. DaveB

    James Kanze Guest

    On Apr 2, 5:33 pm, red floyd <> wrote:
    > On Apr 2, 8:25 am, Branimir Maksimovic <> wrote:


    [...]
    > > Is there possibility for implementation not to use vptr
    > > at all? Eg implementation that would dispatch on 'if's'
    > > based on type? Eg where indirect function calls are expensive?


    > I can imagine a vptr-less implementation, where each virtual
    > function is implemented as a pointer within each object,
    > rather than a vtbl implementation, where such pointers are a
    > per-class thing. So to talk about the vptr at all is
    > nonsense, especially since it isn't mandated.


    A more likely implementation would be to use a hash table
    mapping the object's address to a vtbl, at least based on the
    suggestions I've heard. But I rather like your idea; a compiler
    could use it whenever the number of virtual functions is less
    that some specific number, switching to the vptr if it is
    larger. You obviously don't want to use it for objects with
    hundreds of virtual functions, but some common uses will only
    have one or two virtual functions, and it might represent a
    significant gain in performance in such cases.

    --
    James Kanze
     
    James Kanze, Apr 3, 2010
    #14
  15. DaveB

    James Kanze Guest

    On Apr 3, 1:40 pm, "Alf P. Steinbach" <> wrote:
    > * red floyd:


    > > On 4/2/2010 2:12 PM, DaveB wrote:
    > >> [insult to a member of the Committee redacted]


    > > *PLONK*


    > Well, there was a bit of insult, true.


    > On the other hand, I fail to see what James' state as a member
    > of the standardization committee has to do with anything.


    I don't think it does (especially since I haven't been
    particularly active lately). On the other hand, calling an
    accurate and precise description of the issues "technical
    gibberish" gives a very good idea of the competence (technical
    and otherwise) of the poster. One gets the feeling that he
    prefers to ignore real issues.

    --
    James Kanze
     
    James Kanze, Apr 3, 2010
    #15
  16. * James Kanze:
    > On Apr 2, 4:25 pm, Branimir Maksimovic <> wrote:
    >> On Fri, 2 Apr 2010 08:02:20 -0700 (PDT)
    >> James Kanze <> wrote:
    >>> On Apr 2, 12:16 pm, "DaveB" <> wrote:

    >
    > [...]
    >> Is there possibility for implementation not to use vptr
    >> at all?

    >
    > In theory, at least. As someone (I think it was Alf), all
    > compilers do use a vptr in practice.


    Yes, I wrote that.

    But regarding the question at hand, one alternative is some other kind of object
    -> type association, and an actual search up the base class chains, which is
    roughly how the C++ standard specifies the effect of a virtual call, and is
    roughly how Smalltalk actually did the dispatching.

    And I think Borland C++ once did that for methods outfitted with (language
    extension) integer id's; it was an event handling scheme tailored for Windows
    window messages. Or perhaps it was only in Borland Pascal. But anyway.


    Cheers,

    - Alf
     
    Alf P. Steinbach, Apr 3, 2010
    #16
  17. DaveB

    DaveB Guest

    James Kanze wrote:
    > On Apr 3, 1:40 pm, "Alf P. Steinbach" <> wrote:
    >> * red floyd:

    >
    >>> On 4/2/2010 2:12 PM, DaveB wrote:
    >>>> [insult to a member of the Committee redacted]

    >
    >>> *PLONK*

    >
    >> Well, there was a bit of insult, true.

    >
    >> On the other hand, I fail to see what James' state as a member
    >> of the standardization committee has to do with anything.

    >
    > I don't think it does (especially since I haven't been
    > particularly active lately). On the other hand, calling an
    > accurate and precise description of the issues "technical
    > gibberish" gives a very good idea of the competence (technical
    > and otherwise) of the poster. One gets the feeling that he
    > prefers to ignore real issues.


    The question remains open. Maybe someone NOT in the priesthood of
    technobabblery can answer it.
     
    DaveB, Apr 4, 2010
    #17
  18. DaveB

    Bo Persson Guest

    DaveB wrote:
    > James Kanze wrote:
    >> On Apr 3, 1:40 pm, "Alf P. Steinbach" <> wrote:
    >>> * red floyd:

    >>
    >>>> On 4/2/2010 2:12 PM, DaveB wrote:
    >>>>> [insult to a member of the Committee redacted]

    >>
    >>>> *PLONK*

    >>
    >>> Well, there was a bit of insult, true.

    >>
    >>> On the other hand, I fail to see what James' state as a member
    >>> of the standardization committee has to do with anything.

    >>
    >> I don't think it does (especially since I haven't been
    >> particularly active lately). On the other hand, calling an
    >> accurate and precise description of the issues "technical
    >> gibberish" gives a very good idea of the competence (technical
    >> and otherwise) of the poster. One gets the feeling that he
    >> prefers to ignore real issues.

    >
    > The question remains open. Maybe someone NOT in the priesthood of
    > technobabblery can answer it.


    I think we have already seen the answer:

    In some cases it might be that a vptr is the first member of an
    object. The only exception is when it is not, or when there isn't
    exactly one vptr in the object.
     
    Bo Persson, Apr 4, 2010
    #18
  19. DaveB

    Robert Fendt Guest

    And thus spake Paul N <>
    Fri, 2 Apr 2010 03:20:07 -0700 (PDT):

    > Just out of curiosity, I thought the compiler was obliged to put the
    > first member at offset zero? If so (and it could well be I'm wrong
    > here...) then it must put the vptr (assuming there is one) somewhere
    > else?


    Only for classes where interoperability with C is provided ('POD
    types'). In practice, it usually works that way as long as no
    virtual functions are involved, though the constraints on PODs
    are a bit more severe, IIRC.

    Regards,
    Robert
     
    Robert Fendt, Apr 4, 2010
    #19
  20. DaveB

    DaveB Guest

    Bo Persson wrote:
    > DaveB wrote:
    >> James Kanze wrote:
    >>> On Apr 3, 1:40 pm, "Alf P. Steinbach" <> wrote:
    >>>> * red floyd:
    >>>
    >>>>> On 4/2/2010 2:12 PM, DaveB wrote:
    >>>>>> [insult to a member of the Committee redacted]
    >>>
    >>>>> *PLONK*
    >>>
    >>>> Well, there was a bit of insult, true.
    >>>
    >>>> On the other hand, I fail to see what James' state as a member
    >>>> of the standardization committee has to do with anything.
    >>>
    >>> I don't think it does (especially since I haven't been
    >>> particularly active lately). On the other hand, calling an
    >>> accurate and precise description of the issues "technical
    >>> gibberish" gives a very good idea of the competence (technical
    >>> and otherwise) of the poster. One gets the feeling that he
    >>> prefers to ignore real issues.

    >>
    >> The question remains open. Maybe someone NOT in the priesthood of
    >> technobabblery can answer it.

    >
    > I think we have already seen the answer:
    >
    > In some cases it might be that a vptr is the first member of an
    > object. The only exception is when it is not, or when there isn't
    > exactly one vptr in the object.


    I didn't see that one, and it points the direction to the answer I was
    looking for. I was looking for someone who knows about a number of
    "mainstream" compilers and can expound on the implementations of vptrs in
    those. The assumption, or hope, being that "all" compilers use vptrs
    rather than some other way. I asked more generally than I needed to know,
    but the added information from someone who had it was easy enough to ask
    for. Particularly, though, I wanted to know about gcc because between
    that and VC, I my target platform is covered by those 2, and I am using
    PLATFORM loosely here. I don't use multiple inheritance and am not
    worried about anything strange happening in some remote corner case, and
    if I was, I would have given more information than just "where is that
    dang vptr!?". What I am doing that makes me need that information is not
    relevant, and none of anyone's business unless I volunteer it. For
    someone (not you in this post) to say that the question has been finely
    answered, while I still have not the information I solicited, is pompous,
    or at least seems so with a high degree of certainty, not to let a
    sleeping dog alone, of course.
     
    DaveB, Apr 5, 2010
    #20
    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,258
    tragomaskhalos
    Sep 15, 2006
  2. pai
    Replies:
    4
    Views:
    952
  3. Subhransu Sahoo

    A basic doubt on VPTR and VTABLES

    Subhransu Sahoo, Nov 7, 2006, in forum: C++
    Replies:
    4
    Views:
    354
  4. Rahul

    vptr

    Rahul, Nov 4, 2007, in forum: C++
    Replies:
    3
    Views:
    666
    =?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=
    Nov 4, 2007
  5. Jesse B.
    Replies:
    9
    Views:
    249
    Jesse B.
    Mar 27, 2010
Loading...

Share This Page