Is the vptr at the beginning of an object?

[DaveB]

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.

 

[James Kanze]

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.)

 

[Paul N]

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?

 

[Alf P. Steinbach]

* Paul N:

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

 

[DaveB]

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!

 

[Ian Collins]

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

He did answer the question!

 

[DaveB]

He did answer the question!

He can speak for himself!

 

[James Kanze]

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.

 

[red floyd]

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.

 

[DaveB]

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).

 

[red floyd]

[insult to a member of the Committee redacted]

*PLONK*

 

[Alf P. Steinbach]

* red floyd:

[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".

 

[James Kanze]

[...]

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]

On Apr 2, 8:25 am, Branimir Maksimovic <[email protected]> wrote:

[...]

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]

* red floyd:

[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.

 

[Alf P. Steinbach]

* James Kanze:

On Apr 2, 12:16 pm, "DaveB" <[email protected]> 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

 

[DaveB]

* 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.

 

[Bo Persson]

* 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.

 

[Robert Fendt]

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

 

[DaveB]

* 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.