Скачать или смотреть C++ Tutorial #60 : Why care about virtual function implementation anyway?

Watch Entire Series: http://www.youtube.com/view_play_list...

Isn't it enough just to know how to use it? And what about not relying on implementation details huh? Isn't that worthy of a "programmer's death penalty"? ... What about that?

Eh? ...

--------------------------------------------------------------

So, why does any of this matter in the first place?

1. DISALLOW_OVERRIDE (knowing v-depth and lacking "sealed", an assertion can be created to force compliance). Note how disallowing overrides, as I've implemented it, (demonstrated in the video) actually requires virtual functions, but only for override "detection"; the release versions are not virtual.

2. Disallow "further inheritance". Limit the inheritance depth by sealing all virtual members at once. This is the "final" keyword in Java. Simply stop compile (or execution) through a compile-time or run-time ASSERT based on the size of the 'vtable array'.

3. 'vtable' is in read-only memory (.rdata). So vtable entries can never be overwritten. Thus every additional inheritance requires its own table by force of "impossibility to do otherwise". It follows immediately that a vtable uniquely identifies an object's type. So given an object and knowing (at least *some of*) the vtable list (by brute force at start-up say) allows one to "un-virtualize" a pointer and call its members directly. Why is that desirable? ...

4. ex. Bank software. Perhaps one could find a way to use this knowledge to implement direct-call/virtual-call mixture you may get the flexibility of virtual functions while minimizing pipeline stalls (or deciding what should never be virtual since its "virtual" address is unchanging throughout the 'vtable array').

-------------------------------------

Other answers...
1. Because it's interesting? The question, although apparently open ended, "apparently" leads to only one answer. That is, it seems there are general principles guiding the implementation and so it's probable that the set of all implementations is probably quite small.

2. Knowing the details of an implementation helps you to write better code. Although as I said before, you can't rely on such details!

3. Although generally not a good idea, given your known compiler, you can check things that dynamic_cast for instance, won't (actually "can't") tell you. That is, you now know, and I do too, one can easily check if an "up-cast" from your type exists. That may indicate an error (ex. you've been "passed back" a pointer that you didn't initially allocate - that's obviously an error). An example of this use is demonstrated in the video.