same overhead in calling virtual and non virtual member function...?

[ypjofficial]

Hello All,

So far I have been reading that in case of a polymorphic class ( having
at least one virtual function in it), the virtual function call get
resolved at run time and during that the vtable pointer is made use
of..

eg.
class one
{
virtual void fun1(){ cout<<"one::fun 1";} //This is a virtual
function.
void fun2(){ cout<<"one ::fun2";}//Not a virtual function.

};

int main()
{
one * o = new one;
o->fun1();
o->fun2();
delete o;
o= NULL;
return 0;
}

so when the virtual function gets called through the base class poitner
the call actually gets expanded to the code like this
o->vfptr[0]();
My confusion is how the call to the non virtual function (here fun2
)gets resolved in polymorphic class?
When does the compiler decide to look into the vtable and when not to
look?
As in this scenario I strongly feel that, every time the compiler has
to look into the vtable irrespective of the virtuality or non
virtuality of the function.If it finds the function entry in the vtable
then it calls the function from there otherwise if it doesn't find any
entry into the vtable it looks for the non virtual function and then
execute the fuction code?
So in other words whenever your class is polymorphic , we have to deal
with this overhead always whether the class user calls the virtual or
non virtual function...

Can anyone please clarify it..?

Thanks and Regards,
Yogesh Joshi
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Alf P. Steinbach]

* yp*********@ind iatimes.com:

As in this scenario I strongly feel that, every time the compiler has
to look into the vtable irrespective of the virtuality or non
virtuality of the function.If it finds the function entry in the vtable
then it calls the function from there otherwise if it doesn't find any
entry into the vtable it looks for the non virtual function and then
execute the fuction code?

No.

First off, the language does not require a vtable, although in practice
all implementations you're likely to encounter are vtable-based.

If a function is non-virtual the function address (where its code
resides in memory) is known at compile time, at least symbolically.
That's all you need to issue a call to the function. When a function is
virtual and is called virtually in the source code, the function address
is not necessarily known at compile time, because it then depends on the
object the function is called on, so in that case the compiler may have
to insert code that looks up the function address in the vtable
specified by the object.

<netiquette>
By the way, please don't cross-post to clc++ and clc++m.

Generally you get answers faster in clc++, but when you're crossposting
to a moderated group every article is held up in all groups until it's
accepted (or rejected), so you don't get faster answers: at best you
gain a somewhat broader audience, but some answers you'd otherwise have
had may not be posted (because some posters don't care to wait for the
turnaround of a moderated group), some answers you'd otherwise have had
may be rejected, you run a much higher chance of thread drift, and
you're annoying and worse those who unwittingly reply to your clc++
article expecting their response to show up more or less immediately.

Multiposting -- posting separately -- is an even worse idea, because
the poster then Really Annoys those who reply in one group only to find
the same article posted separately in another group.

A month or two ago there was a surge of multiposting in clc++m. I
generally think of those who multi-post without reason as being either
idiots or non-caring egoists or both (unless they are clearly
first-timers on the net), and I would not be surprised if that's how
most others also view them. Happily multi-posting is not what you did
here, but don't do it. ;-)
</netiquette>

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[James Kanze]

Greg Herlihy wrote:

yp*********@ind iatimes.com wrote:

So far I have been reading that in case of a polymorphic class ( having
at least one virtual function in it), the virtual function call get
resolved at run time and during that the vtable pointer is made use
eg.
of..

class one
{
virtual void fun1(){ cout<<"one::fun 1";} //This is a virtual
function.
void fun2(){ cout<<"one ::fun2";}//Not a virtual function.

};

so when the virtual function gets called through the base class poitner
the call actually gets expanded to the code like this
o->vfptr[0]();

Yes, at least for C++ compilers that use vtables to implement
virtual functions. But the general point is that one function
call to a virtual method in the source code can - at runtime -
execute any of several distinct methods (based on the runtime
type of the object) each and every time. So calling a virtual
method requires run-time decision-making which is not needed
when calling non-virtual methods or global functions.

My confusion is how the call to the non virtual function
(here fun2)gets resolved in polymorphic class? When does
the compiler decide to look into the vtable and when not to
look?

The compiler generates "lookup-code" when the method being called has
been declared virtual, otherwise it generates a direct call to the
method as determined by the object's static type.

More strictly speaking: if the compiler doesn't know at compile
time which function to call, it must generate code to determine
this at run-time. By definition, if the function isn't virtual,
the compiler does know this at run time. If the function is
virtual, it may or may not know it, depending on how good it is.
Almost all compilers will know it if the call is through an
actual object; if the call is through a reference or a pointer,
it depends on the quality of the optimizer.

--
James Kanze (Gabi Software) email: ka*********@neu f.fr
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]