virtual mechanism acivation

[mangesh]

virtual mechanism is activated on pointers only , not on objects .
what is reason beind this .

Regards
Mangesh .

 

[Tomás]

mangesh posted:

virtual mechanism is activated on pointers only , not on objects .
what is reason beind this .

Regards
Mangesh .

Explain yourself in more than the bare minimum amount of words and maybe
people will be more enthusiastic to help you.

Virtual functions retain their "virtualism" regardless of how they're
called. (unless ofcourse you explicitly specify that you don't want
virtualism, e.g.:

Derived derived;

Base &base = derived;

base.Base::Func();


-Tomás

 

[Victor Bazarov]

virtual mechanism is activated on pointers only , not on objects .
what is reason beind this .

It is also "activated" on references, just as well.

The reason is simple. If you have an object, there is no need to
"activate" any "virtual mechanism" because the type is known at the
compile-time. With pointers the "real" type, the type with which
the top-most object was created, is unknown at compilation. Hence
the need (or the capability) to dispatch those calls dynamically.

What I mean is that when you have a pointer (or a reference) to some
class, the compiler thinks that it can be working with a sub-object
of another object, with an object of a base class, whereas the "real"
object is of the derived class. There is a way to know, mind you,
but it involves the same "virtual mechanism", and it's only possible
to know at run-time, not compile time.

V

 

[Tomás]

Tomás posted:

mangesh posted:



Explain yourself in more than the bare minimum amount of words and maybe
people will be more enthusiastic to help you.

Virtual functions retain their "virtualism" regardless of how they're
called. (unless ofcourse you explicitly specify that you don't want
virtualism, e.g.:

Derived derived;

Base &base = derived;

base.Base::Func();

After reading Victor's response, I realised that you were most likely
referring to the compiler actually churning the gears to dereference a
function pointer and so forth... so, to clarify:

Derived derived;

derived.SomeVirtualFunc(); /* No need to consult V-Table */


Derived * const p = &derived;

p->SomeVirtualFunc(); /* Gears start churning (however the compiler
can cleary see where the pointer got
its value from, so it'll probably optimize away
the necessity to consult the V-Table */


Derived &ref = derived;


ref.SomeVirtualFunc(); /* Gears start churning (chance for
optimization again here */


-Tomás

 

[Jonathan Mcdougall]

virtual mechanism is activated on pointers only , not on objects .
what is reason beind this .

Think about it. Try to find an example where

1) you have an automatic object
2) you call a member function on it
3) that member function would be different if the "virtual mechanism"
was "activated"

Compare a case where you call a member function through 1) a pointer or
a reference and 2) an object. Do you see a difference? Do you think it
is possible for a pointer to a Base (Base*) to point toward something
else than a Base? Could a Base* actually point toward a Derived object?
(hint: yes)

Now, do you think it is possible for an automatic object (that is, an
object on the stack) to "point to" something else? Is an automatic
object's static type (at compile time) different from it's dynamic type
(at runtime)?

When you have an automatic object, its type is known at compile time.
The member functions called on it are thus bound at compile time also.
The static type of a pointer (or reference) may be different from its
dynamic type. That's what virtual functions are for: they are called on
the dynamic type of the object. Functions are therefore "decided" (or
"dispatched") at runtime.


Jonathan