Thread: overhead of virtual functions

  1. #1
    Spam is Good
    Join Date
    Jan 2009
    In a cave on Mars

    overhead of virtual functions

    Which of the following options describe the expected overhead for a class that has 5 virtual functions?

    A. Every object of the class holds the address of a link list object that holds the addresses of the virtual functions.
    B. Every object of the class holds the address of the first virtual function, and each function in turn holds the address of the next virtual function.
    C. Every object of the class holds the address of a structure holding the addresses of the 5 virtual functions.
    D. Every object of the class holds the addresses of the 5 virtual functions.
    E. Every object of the class holds the address of the class declaration in memory, through which the virtual function calls are resolved.

    Ok, I would say:
    * A I'm unsure - the object class has a vtable which stores a table of addresses to the virtual function, but is this a link list?
    * B is incorrect has that is not how the vtable works
    * C is incorrect, for the same reason as B
    * D is correct because that describes the vtable correctly.
    * E is incorrect, for the same reason as B

    Can someone please confirm. Thx.
    "What comes around, goes around"

  2. #2
    The larch
    Join Date
    May 2006
    Try again

    #include <iostream>
    #define VIRT_FUNC(x) virtual void x() {}
    struct Test
        int n;
    int main()
        std::cout << sizeof(Test) << '\n';
        Test* t = new Test;
        std::cout << t << ' ' << &t->n << '\n';
    (Although I don't think the standard actually specifies how the virtual mechanism needs to be implemented.)
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  3. #3
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    It doesn't. If a compiler writer wants to implement this as #A or #D, he can. It would be really stupid, though.
    All the buzzt!

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #4
    Join Date
    Oct 2007
    Inside my computer
    I think this is a silly question that should be avoided, because each compiler is not required to implement it in the same way. Plus knowing this knowledge would do you no good, mostly, since trying to put it to use would likely be undefined.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Farncombe, Surrey, England
    In general, it is true that the compiler do not define how vtables are stored [or indeed that it is a "table" in any way - it just defines that the code should behave in a certain way when using the virtual keyword. How that is solved is entirely up to the compiler]

    However, I have worked on code that assumes that the first thing in the memory inside the class is a vtable. The situation is that we have two objects that need to be distinguished through a void * because of the actual code receiving the pointer is a void * [because the pointer is passed across a C interface back to some C++ code], and we have no way to modify one of the classes for legacy reasons - the other class we do have full control over. Since the first class has virtual functions, and the second class DOESN'T, we put a "magic word" into the first element of the second class, which has properties that are UNLIKELY to ever be a valid vtable pointer, such as making sure that it is an odd value - and we use this MAGIC value to determine it is the new class, if that fails then validate that the "non-magic" value "is likely to be a vtable pointer" - if someone passes in some suitably incorrect pointer, we may mistake it for the first type of class - stupid users may be rewarded with a crash, but no legacy code SHOULD do that, and the old code didn't validate the pointer at all - so it would crash then too if a bad pointer was passed in [aside from the obvious check of a NULL pointer].

    The comment to the function that uses the above trickery also explains that the the trickery IS implementation dependant, and may break with certain compilers. So far, it's been compiled with four different compiler versions, from three different vendors, and it's working correctly in all of those. But it is by no means absolutely certain to work IN ALL possible instances.

    I'm not suggesting this as "GOOD" solution - and it certainly isn't super-portable.

    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. i need a good example of virtual functions
    By Anddos in forum C++ Programming
    Replies: 10
    Last Post: 02-15-2006, 11:48 AM
  2. Virtual Functions
    By guda in forum C++ Programming
    Replies: 3
    Last Post: 11-16-2004, 04:13 PM
  3. Thread creation on virtual functions
    By gustavosserra in forum C++ Programming
    Replies: 13
    Last Post: 10-14-2004, 08:03 AM
  4. recursive virtual functions
    By ygfperson in forum C++ Programming
    Replies: 0
    Last Post: 05-25-2003, 08:00 PM
  5. Exporting Object Hierarchies from a DLL
    By andy668 in forum C++ Programming
    Replies: 0
    Last Post: 10-20-2001, 01:26 PM