is the v-table global ?

[Preets]

Is the v-table, that gets generated by the compilation of a class
having virtual functions, global ? Why and how ?

[mlimber]

Preets wrote:

Is the v-table, that gets generated by the compilation of a class
having virtual functions, global ? Why and how ?

A vtable (if it exists) is implicit -- i.e., not explicitly accessible
to you. For certain rare circumstances, you might need to access it,
but doing so is platform-dependent. Compiler vendors are free to
organize it however they wish and may in fact implement virtual
functions by some other mechanism altogether (though I'm not aware of
any that do). Thus, any specific discussion on vtables should be taken
to the newsgroup related to your compiler/platform (consult
http://www.parashift.com/c++-faq-lit...t.html#faq-5.9 for some
possibilities). See this FAQ for some detail on how your vtable *might*
work:

http://www.parashift.com/c++-faq-lit....html#faq-20.4

Cheers! --M

[Ron Natalie]

Preets wrote:

Is the v-table, that gets generated by the compilation of a class
having virtual functions, global ? Why and how ?

A v-table is a behind-the-scenes implementation detail. You are
not required to know how it works, only its effects: virtual
functions and RTTI.

In practice, it's a application wide statically allocated data
(one per polymorphic class). It's not really proper to use the
word "global" because it's not "accessible " at all so scoping
really has no applicability.

[Tom Widmer]

Preets wrote:

Is the v-table, that gets generated by the compilation of a class
having virtual functions, global ? Why and how ?

First of all, vtables are an implementation artifact - C++ doesn't
require them. For example, virtual dispatch can be handled by the
compiler generating code that switches on the dynamic type of an object
(in some cases this is more efficient, since it allows inlining of
virtual calls).

Where the compiler uses them, vtables are generally global (though
dynamic linking can complicate this), since due to the one definition
rule, there can be only one definition of any particular type, so you
only need 1 vtable for each type that has virtual functions. Then, when
you create an object of a particular type, a pointer embedded in that
object is set to point to the relevant vtable.

As for the how, compilers tend to use heuristics to determine exactly
which translation unit (e.g. .o or .obj file) to put the vtable into.
This might be the .c file that contains the definition of the first
defined virtual function of the class, or if no such file exists (e.g.
because every function of the class is defined inline), the vtable is
emitted in every TU that needs it, and then they are coalesced at the
end by the linker.

Tom

[Preets]

I found the mention about global v-table at this link....
-->> http://www.parashift.com/c++-faq-lit...functions.html
under the section
-->> [20.3] What's the difference between how virtual and non-virtual
member functions are called?

To quote:
-->> if the object has one or more virtual functions, the compiler puts
a hidden pointer in the object called a "virtual-pointer" or
"v-pointer." This v-pointer points to a global table called the
"virtual-table" or "v-table."

[mlimber]

Preets wrote:

I found the mention about global v-table at this link....
-->> http://www.parashift.com/c++-faq-lit...functions.html
under the section
-->> [20.3] What's the difference between how virtual and non-virtual
member functions are called?

To quote:
-->> if the object has one or more virtual functions, the compiler puts
a hidden pointer in the object called a "virtual-pointer" or
"v-pointer." This v-pointer points to a global table called the
"virtual-table" or "v-table."

Yes, but I would emphasize that that FAQ also says, "*Most* compilers
use some variant of the following technique...", and the following FAQ
provides the disclaimer, "Th[is] answer is entirely compiler-dependent,
so your mileage may vary, but most C++ compilers use a scheme similar
to the one presented here."

Cheers! --M