Hi..

Every class which has a virtual function has Vtable, and every object
of it has vptr..Does that mean..
For class it will be annotated to static array of pointers [vtbl] and
a non static pointer (vptr) which points this vtbl..

Am i talking right?

doublemaster007@gmail.com wrote:
> Hi..
> 
> Every class which has a virtual function has Vtable,

That's a common implementation of virtual functions nowadays.  It is not 
mandated nor is it guaranteed by the Standard.

 > and every object
> of it has vptr..Does that mean..
> For class it will be annotated

"Annotated"?

 > to static array of pointers [vtbl] and
> a non static pointer (vptr) which points this vtbl..
> 
> Am i talking right?

Uh...  What are you trying to say?  Perhaps you should just draw a 
picture...

A good explanation of how this works is given in "Inside the C++ Object 
Model" by Stanley Lippman (IIRC).

V
-- 
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Victor Bazarov wrote:
> doublemaster007@gmail.com wrote:
>> Hi..
>>
>> Every class which has a virtual function has Vtable,
> 
> That's a common implementation of virtual functions nowadays.  It is not 
> mandated nor is it guaranteed by the Standard.

Is there any different implementation?

-- 
Max

Maxim Yegorushkin wrote:
> Victor Bazarov wrote:
>> doublemaster007@gmail.com wrote:
>>> Hi..
>>>
>>> Every class which has a virtual function has Vtable,
>>
>> That's a common implementation of virtual functions nowadays.  It is 
>> not mandated nor is it guaranteed by the Standard.
> 
> Is there any different implementation?
> 

I don't know of any.  But the absence of proof is not the proof of absence.

V
-- 
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

On Dec 1, 9:09=A0am, Maxim Yegorushkin <maxim.yegorush...@gmail.com>
wrote:
> Victor Bazarov wrote:
> > doublemaster...@gmail.com wrote:
> >> Hi..
>
> >> Every class which has a virtual function has Vtable,
>
> > That's a common implementation of virtual functions nowadays. =A0It is =
not
> > mandated nor is it guaranteed by the Standard.
>
> Is there any different implementation?


Even if no implementation uses a different mechanism than the
traditional vtable, small (virtual) classes can often be entirely
inlined in the right circumstances (obviously where the type is known
by some analysis of the flow graph), and the vtable (and perhaps much
else) can be omitted.  So at best there's a vtable for a virtual
class, unless some compiler uses some other scheme, or a compiler
decides it can omit it for other reasons.  IOW, don=92t count on it.

On 01/12/09 21:27, robertwessel2@yahoo.com wrote:
> On Dec 1, 9:09 am, Maxim Yegorushkin<maxim.yegorush...@gmail.com>
> wrote:
>> Victor Bazarov wrote:
>>> doublemaster...@gmail.com wrote:
>>>> Hi..
>>
>>>> Every class which has a virtual function has Vtable,
>>
>>> That's a common implementation of virtual functions nowadays.  It is not
>>> mandated nor is it guaranteed by the Standard.
>>
>> Is there any different implementation?
>
>
> Even if no implementation uses a different mechanism than the
> traditional vtable, small (virtual) classes can often be entirely
> inlined in the right circumstances (obviously where the type is known
> by some analysis of the flow graph), and the vtable (and perhaps much
> else) can be omitted.  So at best there's a vtable for a virtual
> class, unless some compiler uses some other scheme, or a compiler
> decides it can omit it for other reasons.  IOW, don�t count on it.

True. However, this is a general optimization which could be applied to 
pretty much arbitrary objects and members. Not specific to virtual 
functions and vtables.

-- 
Max

On 01/12/09 15:27, Victor Bazarov wrote:
> Maxim Yegorushkin wrote:
>> Victor Bazarov wrote:
>>> doublemaster007@gmail.com wrote:
>>>> Hi..
>>>>
>>>> Every class which has a virtual function has Vtable,
>>>
>>> That's a common implementation of virtual functions nowadays. It is
>>> not mandated nor is it guaranteed by the Standard.
>>
>> Is there any different implementation?
>>
>
> I don't know of any. But the absence of proof is not the proof of absence.
>

I wonder how they came up with this implementation.

Probably, they thought it would be nice to have (run-time) polymorphism 
like in other popular OO languages at that time, like Smalltalk. So, the 
next question could probably have been how it was currently done in C. 
Well, in C it is a common pattern to declare a structure of function 
pointers (vtable concept) and have a pointer to such a structure in an 
object (vtable pointer concept). The would be one instance of that 
structure for every different object type. Next, they probably thought 
that it would be nice if the compiler could generate these function 
pointer structures and stick the pointer into object automatically. To 
do so there needed to be a way to let the compiler know that a (member) 
function needed to be in that structure. One straightforward way was to 
mark/annotate that function with a keyword, like sticking a virtual in 
front of the function declaration. This could have been how virtual 
keyword for functions came about. They did that and they saw that it was 
good. And then they forgot to document that in the standard so that 
people would guessing in the newsgroups till the end of times, and there 
would be one more item on the list when defining a C++ ABI ;)

-- 
Max

On Dec 1, 7:56=A0pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> doublemaster...@gmail.com wrote:
> > Hi..
>
> > Every class which has a virtual function has Vtable,
>
> That's a common implementation of virtual functions nowadays. =A0It is no=
t
> mandated nor is it guaranteed by the Standard.
>
> =A0> and every object
>
> > of it has vptr..Does that mean..
> > For class it will be annotated
>
> "Annotated"?
>
> =A0> to static array of pointers [vtbl] and
>
> > a non static pointer (vptr) which points this vtbl..
>
> > Am i talking right?
>
> Uh... =A0What are you trying to say? =A0Perhaps you should just draw a
> picture...
>

I just wanted to know the types of vtbl and vptr..to know whatever i
have understood is correect.
So could you pls tell me the types of vptr and vtbl.

As per my understanding vtbl is static array of function pointer
[static because its in class level]
vptr is non static pointer [since every object has its copy]

> A good explanation of how this works is given in "Inside the C++ Object
> Model" by Stanley Lippman (IIRC).

After reading this book only i got this doubt...
>
> V
> --
> Please remove capital 'A's when replying by e-mail
> I do not respond to top-posted replies, please don't ask

doublemaster007@gmail.com wrote:
> [..]
> As per my understanding vtbl is static array of function pointer
> [static because its in class level]
> vptr is non static pointer [since every object has its copy]

Well, this is basically correct.  Except that neither vtbl, nor vptr are 
visible to the user of the class (or even the class itself) through the 
language means.  There is no portable way to say 'MyClass::__vtbl' and 
get the [pointer to the] array, or 'MyClassInstance.__vptr' and get the 
local copy of the actual virtual function table pointer.  [Note: the 
syntax is made up to illustrate the point]

V
-- 
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

On Dec 2, 5:25 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> doublemaster...@gmail.com wrote:
> > [..]
> > As per my understanding vtbl is static array of function pointer
> > [static because its in class level]
> > vptr is non static pointer [since every object has its copy]

> Well, this is basically correct.  Except that neither vtbl,
> nor vptr are visible to the user of the class (or even the
> class itself) through the language means.  There is no
> portable way to say 'MyClass::__vtbl' and get the [pointer to
> the] array, or 'MyClassInstance.__vptr' and get the local copy
> of the actual virtual function table pointer.  [Note: the
> syntax is made up to illustrate the point]

More to the point, they may not have a type which can be
expressed in C or C++.  All you can really say is that the vptr
points to some class specific meta information (called the
vtable or vtbl) and that this meta information includes all the
information necessary for virtual function calls and
RTTI---considerably more, in fact, than just pointers to
functions.  (The names, and the idea that the vtbl is just a
table of pointers to functions, come from the earliest versions
of CFront: before multiple inheritance and RTTI were introduced
to the language, the vtbl was just a table of pointers to
functions, and CFront used C as its intermediate language, and
in this generated C, the names were __vptr and
__vtbl__classname, or something like that.)

--
James Kanze