13

For those compiler implementations that use vtables: are there any cases when virtual functions tables are changed at run time? Or are vtables only filled at compile time, and no actions are performed to modify them at run time?

Paul Roub
  • 36,322
  • 27
  • 84
  • 93
Karolis Milieška
  • 621
  • 5
  • 15
  • 2
    What sort of runtime modifications do you envisage being useful/possible? – Lightness Races in Orbit Apr 17 '16 at 08:37
  • 2
    @Cheersandhth.-Alf if it's a plain C++ program than no, it's silly. but if he (now or in the future) will have to write something like VM or a interperter/JIT compiler than I wouldn't discard his question so quickly – David Haim Apr 17 '16 at 09:42
  • It's imp... very difficult to come up with such a design that is thread-safe, so it's not done. – Martin James Apr 17 '16 at 10:48
  • If the vtables need to be modified at runtime, they have to be in a writeable section. Another word for 'writeable 'is 'hackable':( – Martin James Apr 17 '16 at 10:52
  • 1
    The most obvious case is the constructor of the class. It runs with another v-table that prevents virtual functions from being virtual, implementing required C++ behavior. Swapped with the regular one at the end of the constructor. We are not allowed to talk about implementation details like that. – Hans Passant Apr 17 '16 at 11:30
  • https://defuse.ca/exploiting-cpp-vtables.htm and http://kaisar-haque.blogspot.ru/2008/07/c-accessing-virtual-table.html give some interesting insights, though you have to have some c++foo, courage and - most important - reason to do these things. Also jyt.io is an upcoming JIT C++ compiler could be relevant – strangeqargo Apr 17 '16 at 14:01
  • Actually, I'm having exactly the same issue now.. The best approximation I could find is member function pointers. – lorro Jun 27 '16 at 19:00

2 Answers2

8

I am not aware of any C++ ABI with a polymorphism implementation that employs virtual tables changing at runtime.

It wouldn't be very useful, anyway, since virtual tables typically describe a property of the code (the relationship of member functions to each other w.r.t. position in class hierarchy) and C++ code doesn't change at runtime.

And because it wouldn't be useful, it would be wasteful.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
3

The short answer is no.

A slightly longer (and probably implementation specific) answer is that the object's pointer to the actual vtable changes during the execution of a constructor and destructor of a derived polymorphic class, so that overridden methods in a derived class do not get executed by the base class's constructor/destructor while the derived class is not yet constructed/has been destructed.

If you want objects to change class during run time then you have a number of options:

  1. objective-c(++)

  2. hand-code your own dispatch mechanism

  3. python/javascript etc al.

  4. (the best option) reconsider your design.

Richard Hodges
  • 68,278
  • 7
  • 90
  • 142
  • 1
    It's not the vtable that changes. It's the vptr member of the object under destruction! – Kerrek SB Apr 17 '16 at 09:13
  • also, `std::function` can be re-assigned at runtime, so this is another option – David Haim Apr 17 '16 at 09:17
  • @KerrekSB fixed, although I'm sure there is better wording – Richard Hodges Apr 17 '16 at 09:26
  • 1
    @DavidHaim I think this would come under the 'roll your own' heading, since he's talking about changing the behaviour of the entire class of objects at run time - there would need to be a mutex around the change, and some mechanism to protect functions that were actually being executed at the time (either copying the std::function or holding a shared_ptr to it, maybe?) – Richard Hodges Apr 17 '16 at 09:28
  • 1
    @RichardHodges yes, I totaly agree with you. I just wanted to mention function objects so it wouldn't look as if "dispatch mechanism" always means something like JIT compiling or messing with th assembly code – David Haim Apr 17 '16 at 09:41