Topic: The internals of vtable


Author: kkelkar@questone.com
Date: 1998/10/26
Raw View
Hi all gurus!

I want to know the exact structure of vtable as it's organized in the memory.
My humble knowledge tells me that it's a table of pointers to virtual member
functions of the class. But I would like to know how exactly is the table
organized, for example, some documentation says that it's simply set of
pointers, which puzzles me by asking how does a pointer map to a particular
function? How a correct function call is made (and how is it located in the
first place) in a late-bound function call? In case of multiple
inheritance, is there a specific sequence?

Thanks for your time
--
Kedar R. Kelkar
kkelkar@questone.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: James Kuyper <kuyper@wizard.net>
Date: 1998/10/26
Raw View
kkelkar@questone.com wrote:

> Hi all gurus!

> I want to know the exact structure of vtable as it's organized in the memory.
> My humble knowledge tells me that it's a table of pointers to virtual member
> functions of the class. But I would like to know how exactly is the table
> organized, for example, some documentation says that it's simply set of
> pointers, which puzzles me by asking how does a pointer map to a particular
> function? How a correct function call is made (and how is it located in the
> first place) in a late-bound function call? In case of multiple
> inheritance, is there a specific sequence?

You'll need to ask on a newsgroup devoted to your particular compiler.
The C++ standard doesn't even mention vtable, much less require that one
exist. Different implementors use different schemes.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1998/10/27
Raw View
In article 1@nnrp1.dejanews.com, kkelkar@questone.com writes:
>
>I want to know the exact structure of vtable as it's organized in the memory.

Vtables are an implementation detail, not part of (or even a requirement
of) the C++ language definition. No two implementations do it quite the
same way, and it is common for a new major release of a given compiler
to make a change in vtable implementation details.

The ARM ("The Annotated C++ Reference Manual", by Ellis & Stroustrup),
pages 217-236, gives two different sample implementations. Some compilers
document how their vtables work.

---
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/10/27
Raw View
In article <711kba$rno$1@nnrp1.dejanews.com>, kkelkar@questone.com
writes
>I want to know the exact structure of vtable as it's organized in the memory.
>My humble knowledge tells me that it's a table of pointers to virtual member
>functions of the class. But I would like to know how exactly is the table
>organized, for example, some documentation says that it's simply set of
>pointers, which puzzles me by asking how does a pointer map to a particular
>function? How a correct function call is made (and how is it located in the
>first place) in a late-bound function call? In case of multiple
>inheritance, is there a specific sequence?

Why would you want to know about something that is entirely
implementation dependent, indeed if some genius can think of a way of
implementing polymorphism in some other way s/he is fully entitled to do
so.

Rule 1 of programming

You should not have to know the internals of a mechanism

Rule 2

Even if you do you should never use that knowledge.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: scott@softbase.com
Date: 1998/10/27
Raw View
kkelkar@questone.com wrote:

> I want to know the exact structure of vtable as it's organized in the memory.

Well, it varies by compiler. The organization of a Visual C++ vtable is
probably the most widely known, since it formed the basis for COM
programming which is well documented. Study COM: if you understand an
interface and its methods, you understand a vtable. They're the same.
Lippman's book on the C++ object model is also a good resource for
understanding "under the covers" of C++.

Scott
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: "Andrei Alexandrescu" <alexandrescua@micromodeling.com>
Date: 1998/10/27
Raw View
>Rule 1 of programming
>
>You should not have to know the internals of a mechanism
>
>Rule 2
>
>Even if you do you should never use that knowledge.


Rule 2 is great, but I disagree with Rule 1 to some extent. Programmers
should know a bit about the implementation of a language feature so they
know what the tradeoffs are. Of course I got the idea of your principle, but
you know, because I know no compiler producer ever optimizes throw/catch
statements (they can be actually one order of magnitude slower than normal
paths), I shouldn't use them to treat normal conditions.

Andrei




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]