IM GOING LIVE TODAY AT 12PM EST TO REVIEW MY CHATS CODE: kzfaq.info-A6Ar4u_Teg

I have a number of issues regarding this video: First, the example given is a exceptionally poor choice. The number of unique cases is far to few for when Polymorphism should properly be used. With only "OP_ADD" and "OP_MUL" as outcomes, the code will compile into conditional jump statements. If there were more cases, the switch statement would likely be compiled into a jump table. This would have been a far better comparison to Polymorphism. As it stands, the video was effectively comparing if-statements to function pointers for a minuscule number of cases. Second, This explanation on how vtables are structured is based on the assumption that the vtable isn't embedded into the object. While I haven't encountered any compilers that do this, actual implementation of an object's vtable isn't standardized. This video can wrongly give off the assumption that it is standardized. Thirdly, in regards to why virtual methods are slow, while it is true that memory operations are slower than operations that take place on registers, the biggest slowdown actually comes from the fact your doing a dynamic jump. Modern CPUs try to fill the execution pipeline with as many instructions as possible with out-of-order execution by looking ahead for independent chains of instructions. This is far easier to do when the control flow of the instructions is static and works especially well when the branch predictor chooses the correct execution path. When a dynamic jump occurs, the processor basically has to halt everything until the memory location of where it's going is loaded into the processor. Forth, I must disapprove of the blanket "This is Bad" approach this video takes. Polymorphism is just like any other tool in programming: there situations where it is good and bad. When choosing what mechanism to use in programming, one needs to compare the benefits and cost. The video you've done shows Polymorphism being used in an inner-most loop. This is quite likely the worst case scenario for polymorphism. It simply isn't worth the overhead that comes with polymorphism. If you wanted to stick with the calculator theme for the video, better options like Square Root, Trigonometric Operations, or Logarithm would have been a fairer comparison. Lastly, the code presented at the start has some problems. Why are you using atoi in the conditional?! The code will be pointlessly executed every pass! Additionally, if you use optimization settings, the compiler might very well optimize away the entire body of the loop! If it tries to inline the operation code, it might very well see that the only one case is ever true and the operand assignments are pointless. This would result in an addition to a temporary variable that is only written to and never read from. Seeing it has no side effects, it might just empty the entire body of the loop. Unless you looked at the assembly, you wouldn't be able to tell how aggressively it optimized the code and if the tests were actually fair.

"It is important to note that by default, functions with the same signature in a derived class are virtual in the parent by default." What? No? This isn't Java.

A non-virtual call is exceptionally fast, as it usually consists of a single instruction. On the other hand, a virtual call introduces an extra level of indirection, leading to the purported 20% increase in execution time. However, this increase is merely "pure overhead" that becomes apparent when comparing calls of two parameterless functions. As soon as parameters, especially those requiring copying, come into play, the difference between the two overheads diminishes. For instance, passing a string by value to both a virtual and a non-virtual function would make it challenging to discern this gap accurately. It's essential to note that the increased expense is primarily confined to the call instructions themselves, not the functions they invoke. The overhead incurred by function calls constitutes a minor proportion of the overall execution time of the function. As the size of the function grows, the percentage representing the call overhead becomes even smaller. Suppose a virtual function call is 25% more costly than a regular function call. In this case, the additional expense pertains only to the call itself, not the execution of the function. It's essential to emphasize this point. Usually, the expense of the function call is much smaller compared to the overall cost of executing the function. However, it is crucial to be cautious because though it may not always be significant, if you excessively use polymorphism, extending it to even the simplest functions, the extra overhead can accumulate rapidly. In C++, and in programming in general, whenever there's a price, there's a gain, and whenever there's a gain, there's a price. It's that simple.

Cool video but i could'nt stop staring at the cpu with the swick sunglasses

In the famous words of Chef "There's a time and place for everything, children. It's called college"

I've been coding a game engine from scratch for a few years now, and in most real scenarios I encounter, where functions perform actual work, the virtual call overhead is just negligible. I tend to avoid using virtuals in a hot path (functions that will run many times per frame), but I'm totally fine using them elsewhere. This is how I dispatch game system update and render calls in my framegraph, for instance. My game systems must have state, and the engine can't know about the specifics of client-side game system implementations. All it knows is that some will modify a scene (update), and some will push render commands in a queue when traversing a const scene (render). So polymorphism is a good tool here: it makes the API clear enough, it makes development less nightmarish, the abstraction it introduces can be reasoned about, and the call overhead is jack shit when compared to execution times. Guys, don't let people decide for you what "sucks" and what is "nice" or "clean". This is ideology, not engineering. Toy examples like this are *not* real code, measure your actual performances and decide for yourself.

I get your point: virtual function have a cost and it's true. But the video is not 100% honest. The c++ code can be extended by only creating new type of operator without touching the code that execute operation. The C code cannot, you must change the central switch case and the enum. The virtual function has a cost but also offer functionality. Do the functionality worth the cost? Maybe yes maybe no. Each case is different and must be evaluated. Also c++ != virtual function and inheritance. It's not because the feature exist you must use it. They are tools in the toolset, nothing more. Then you also did an useless operation the force the c++ to pass by the vtable with the line "Operation *op = &add;". If you just used "add.execute();" directly the compiler you know at compile time what function to call and would not pass by the vtable. I understand you did that to have a one page example. But it could lead someone to think an example this simple would always use overkill feature like the vtable. It make look c++ dumper than it is.

Remember to mark your polymorphic classes as final if they are the final derivation! That lets your compiler optimize virtual function calls into regular function calls in situations where there can be no higher superclass.

You can write OO code in C. C just doesn't do the heavy lifting for you. You can write your own dispatch tables with function pointers. There are plenty of OO libraries for C. GTK+ and Xt are two examples. The code doesn't look as nice, but OO is about how you organize and reason about your code, not about whatever syntactic sugar your language gives you.

Mistake in 03:46: If a derived class has the same function as the parent BUT the parent function isn't marked as virtual it doesn't become virtual implicitly. The 2 functions will co-exist simultaneously. Which one will be called depends on the type of the variable that does the call. Is it base class variable or a derived class variable? Specifically if the pointer is of type base*, you assign it to an instance of derived class and call the overriden function it will actually call the base class's implementation of that function. This is a subtle C++ pitfall that can lead to bugs. What you probably meant to say: If a base class has marked a function as virtual then it becomes implicitly virtual for any derived class. The derived class doesn't have to explicitly mark it as virtual. But for clarity reasons it should do so.

This video shows a only a compaison when C++ virtual approach is disadvanaged and dosen't count the disadvantages of the C switch approach, using that to arrive at a simplistic conlcusion "virtual bad". The example show in this video the number of operation and the operation itself are very small, so here the comparison is "dereferencing a virtual table and call a function" vs "call diretly a slightly bigger function". But if we pass in a more realistic context, where there are more derived classes and bigger method, now in the C approach we have bigger switch that've to call other functions so that means that we've to do 2 function call in C approach insthead of 1 like the C++ approach, with all the overhead that comes to (or put all the logic of all cases in one function and have a massive switch). And THE CACHE MISS CAN HAPPEN EVEN IN C APPORACH TOO, you know the switch has to be loaded form memory too, like a vtable. The C switch has the advantage of being easier to optimize and can be faster, but you've to now and implement the call for every type of operation in the base class. This means that it's not possible to use in situations like extending the functionality of an already compiled library. And last which compiler and flags were used?

I teach college C/C++ and I think the most important part of introducing C++ is explaining the problems that the language was written to solve; they were problems with large scale software development, not writing faster algorithms. Projects were becoming really hard to manage with library name conflicts, simultaneous changes to common code stepping on eachothers toes, human problems like that. Polymorphism lets developers build on top of eachother's code in a way imperative code can't support. Someone could subclass your calculator, add/remove/change operators, and pass the new calculator into existing calculator-using code with no change to your calculator class code and just instantiating a different class in code that depends on your calculator.

80% to 90% of code execution time is spend in 10% to 20% of the code. if your code is performance tuned so much that it's the performance degradation is due to vtable lookup (which I highly doubt), then perhaps you can say "polymorphism sucks". For 99.999% of all programs out there, that's not the case and polymorphism is a very useful feature and makes code simpler.

It's always worth noting that when Stroustrup says that C++ obeys the zero-overhead principle, that in NO way means that the abstraction itself is free. It's just that you couldn't hand-code it better yourself with less performance overhead to use that feature (ideally). If you use inheritance with virtual member function overrides, you *will* pay a cost, because if you care about performance 1. you should always measure it, and 2. you should be aware of exactly how it is implemented. Otherwise, don't solve the problem that way. There are some cases where inheritance is quite applicable, but needless to say, it is not exactly cheap, and its depth should be minimized if it's used at all. And to quote Gang of Four, "Favor object composition over class inheritance".

Incredibly misleading. You're not comparing the same things. Full-fledged polymorphism with virtual calls cannot be compared to a case over an enum. If you were comparing C++ to a function pointer call (with the destination of the pointer compiled in a separate TU and the program compiled without link-time optimisation) in C, that could be considered "comparable" at least.

I think you're missing the point a bit. Every competent C++ knows that virtual functions aren't the most efficient. Using them in "hot" code (e.g. tight loops) causes the "penalty" to exponentially grow. But it's a way to abstract things. The C example here doesn't really abstract anything, whereas the C++ example does. You could compile and run the same C example code in C++. You could change it to use classes (which are just structs after all). Heck, unlike C, you could even turn it into templates and do all kinds of fun stuff and get the compiler to even inline the whole thing, making it potentially even more efficient than the C counterpart. Bottom line is, polymorphism doesn't really "suck" for this reason. The biggest complaint is the complexities that come info play when you inherit from multiple classes at the same time, which many languages don't even allow.

In large project, polymorphism could literally save tons of amount of time and be really helpful to organize the code. Things like OOP, design patterns, are basically just for large projects but not for something small like calculator or some kinda stuff.

I'd say that polymorphism doesn't necessarily suck. Poor use of polymorphism sucks. If your virtual function takes only couple of cycles to complete, then it might not be a good idea to use polymorphism, but when it takes couple of miliseconds, the slowdown caused by the extra lookup is negligible.

Sounds deceptive to say it sucks. It doesn't. However, it's easy to misuse.

Firstly, I'd like to emphasize that polymorphism, like any tool in the programmer's toolbox, has its optimal use cases. It's not inherently 'bad' or 'good', but should be used when appropriate for the problem at hand. An overly narrow focus on performance can inadvertently lead to premature optimization, and it's important to remember the classic Donald Knuth quote: "Premature optimization is the root of all evil". Polymorphism shines in scenarios where you need to process a collection of objects that share a common interface but have different internal behaviors. In these cases, it allows you to write more concise, readable, and maintainable code by avoiding verbose switch-case statements or if-else ladders. Although polymorphism introduces a performance overhead due to the indirection through the vtable, this is often insignificant in comparison to the cost of the actual function execution. And while it's true that in a tight loop this overhead can accumulate, this isn't where polymorphism typically brings the most value. To your point about how vtables are implemented, it's true that there's no standardization across compilers. However, most C++ compilers adopt similar strategies, and the vtable is usually stored separately from the object instance, with a pointer to the vtable added to the object's memory layout. This additional level of indirection can indeed add to the function call cost, and that cost is further compounded by the challenge for CPUs to predict dynamic jumps, as another commenter rightly pointed out. I also agree with the critique about the video's simplistic example. A more complex set of operations would have made the comparison more meaningful, as the benefits of polymorphism become more apparent when you're dealing with larger codebases and more complex behavior differences between classes. Finally, it's worth noting that C++ offers more than one way to achieve polymorphism. Beyond the classical (runtime) polymorphism we're discussing here, there's also compile-time polymorphism, also known as static polymorphism, via templates. The latter can eliminate the runtime overhead, at the expense of potentially increasing the binary size. It's yet another trade-off to consider based on the specific needs of your program. Overall, I think it's crucial not to dismiss polymorphism out of hand because of performance concerns. Instead, we should understand its costs and benefits, and use it where it makes the most sense.

I LOVE polymorphism. Let me tell you why. I've used it in providing an undo/redo feature, as well as in writing an arithmetic parser. It elegantly separates the overall design from the implementation of nodes. So if I have to fix nodal behavior or add new node types over time, I don't have to touch the top level architecture. It. Just. Works. Yes, there is a small performance hit but it's more than worth it to me to have more readable, more maintainable code. That said, one alternative is to use name overloading (what I like to call "static polymorphism"), which is resolved at compile time and solves the performance hit.

This is a nice video but I think it's also a bit misleading... The C code isn't *really* polymorphic: Every 'method' added has its own switch statement, every 'child' added is a new case for every switch in every function and the monolith grows. And the C++, of course it'd be silly to use that kind of indirection on the hot path (and std::visit(); might be preferable). Either way, the compiler will optimize away where possible for the target platform, including switch statements.

You explained very nicely why polymorphic code is slower, but it sucks only if you need to squeeze all possible performance from the hardware by a specific task. Which is the case pretty rarely. The most common scenario is something (I mean, most of the code) is waiting for something slower, meaning it has more than enough time to not create any measurable lag. But yes, when you're optimizing a tight loop and every cycle matters, then the good old C is the way to go. But again it would be pretty tricky to provide a right example. In my practice - if I have a tight loop and I want to save every cycle - I just avoid calling anything, inlining as much as possible. And this can happen inside a C++ overridden method, but it just doesn't matter as long I don't call other other methods from said tight loop. Sometime I mix C with C++, where C++ is for general app logic, and C is doing time critical things. The common C++ usage is for tasks too tedious to code in C and usually not time critical. Like UI and network. The code waits "ages" for something to happen, then you invoke a C function that does the heavy lifting pushing gigabytes of data because the user just moved a mouse or clicked a button.

Good point, but in the calculator example, the C code has conditional code that the C++ code does not have. Believe me, after having programmed in C++ for 30 years, I can assure you that the supposed overhead of polymorphism is negligible in the overall execution time of a real world program.

Not many people can make an 8min long video about polymorphism and such low-level details and still keep it interesting. Well done, bro.

Polymorphism doesn't need to involve dynamic dispatch though. In Rust, for instance, polymorphism can be achieved with generics. And the cool thing about generics is that at compiler time they get monomorphized, i.e. the compiler will just copy-paste the function with every combination of concrete types that it's called with, so you just end up with roughly the same setup you had in C with no performance cost. I haven't had much experience in C++, so I don't know how templates work there, but presumably it would be possible to do the same thing there. Also there are situations where dynamic dispatch is needed, so, if you're writing it in C you'd use function pointers and it would be just as slow as virtual methods.

For such simple operations vtable lookup represents 20% more of execution time but truth is in a real program it would not represent such a high proportion of execution time. And C code might be less easy to maintain down the line

C can be written in OO style (see GObject), it just requires you to manually implement the pattern. An interface in C would be a structure containing function pointers constructed by object specific functions.

std::function, lambdas, concepts etc. v-tables and virtual are rarely actually required and usually just a convenience tool for doing something in a specific way.

Respect for taking the time to write such a critical video. A suggestion I make when writing critical things about a programming language is to let clear when the criticism goes on the language itself (e.g. syntax), and when it goes on implementation aspects. Your criticism is on an implementation aspect, that can be optimized by a compiler. So, if you think well, your criticism isn't on (C++'s) polymorphism.

It's not always about performance, you have to choose wisely what you want to use for your particular use case. If your use case requires raw performance, OOP may not be the way to go. But if you don't want to spend 5 hours debugging your C code, maybe OOP is the way to go. Still, it's very nice to see someone explaining the implementation details of C++. Great work!

About the V-Table, if you use the final specifier on virtual functions this(amongst other things) provides the compiler an opportunity to "devirtualize" the function.

I think that the concept of this video is wrong from the base. I mean: polymorphism sucks... if you need performance. But when what you need is code easily maintenable, and the performance is not a problem, it is a good tool (but don't forget what happens when you only have a hammer...). If performance were the only metric, we would use only assembler/C, and never languages like python, perl or java.

I used polymorphism in writing simulations where the code paths were things like "run this CFD code that takes 20 min" vs "run this approximation that still takes 30 seconds". It made for convenient organization where the child classes would track whatever extra data they needed. The overhead in using virtual functions maybe added a few millionths of a percent to the overall runtime of that particular feature.

Enjoy your videos, it's great to see videos explaining the inner workings of the stuff that we just take for granted now. I think you may have miss spoken a couple of times around 3:32. The "=0" is not needed in order for the compiler to create the v-table entry, this just indicates that the class is only to be derived from and that the derived class must implement this pure virtual function. Non-pure virtual functions (without the =0) need not be implemented in the derived class if the base implementation is appropriate. Also you say that the virtual keyword is not needed and that by simply declaring a function with the same signature in the derived class the compiler will assume the base method to be virtual. I think this is true in some other OO languages, but not in C++. You cannot make a base class virtual without specifying the virtual keyword in the declaration of the base class. It is true that you can declare a function with the same signature in the derived class - this is know as "overriding" (which is not the same as "overloading") - but it will not get an entry in the v-table and will therefore not get called by a method invocation from a base class object. The following g++ program demonstrates this: #include class base { public: void identify(void) {printf("%s ", __PRETTY_FUNCTION__);} virtual void virt_identify(void) {printf("%s ", __PRETTY_FUNCTION__);} }; class derived : public base { public: void identify(void) {printf("%s ", __PRETTY_FUNCTION__);} virtual void virt_identify(void) {printf("%s ", __PRETTY_FUNCTION__);} }; int main(int argc, char *argv[]) { derived d; base *b = &d; b->identify(); // calls base::identify() (not a virtual function) b->virt_identify(); // call derived::virt_identify() (via vtbl) d.identify(); // calls derived::identify() (overrides base::identify()) d.base::identify(); // calls base::identify() (explicitly) b->base::identify(); // calls base::identify() (explicitly, bypasses the vtbl) return 0; } Program output: void base::identify() virtual void derived::virt_identify() void derived::identify() void base::identify() void base::identify()

The basic point you're trying to illustrate about the vtable is correct, but I think we have to clarify a few things. First of all, this is not about C++ but about the code style your're using (runtime polymorphism). If you hadn't used a manual way of creating a function pointer, the compiler would most likely have resolved the polymorphism at compile time. Speaking about compile time, you could also use templates for enforcing compile-timepolymorphism. And modern CPUs are good at resolving indirections like vtables, too. All in all, OOP and polymorphism can be great for structuring code, but I think they're overused.

C++ as a language, is capable of solving the problem introduced in the video faster than C contrary to the argument. If you need to have a “dynamic” operation (like a custom operation for a mapper or a predicate for a filter), on C you are stuck with function pointers (the given enum example is unrelated to the problem space IMO, it is fully static and not bound late at execution time) and they cannot be easily inlined by the compiler as they are only known very late at execution time. C++ OTOH, is capable of doing the inlining at compile time thanks to the superior type system. Overall I think this problem is a pretty bad example for polymorpism. It is just not the correct tool for this use case. Of course there are many ways of achieving the same thing and some of them will perform slower and it is something to consider when picking a solution. For the provided example, a compile-time polymorphism strategy (ie changing the operation at compile time) would perform the same as the C version provided. Note that the C version would not be versatile as you cannot simply provide the operation at the callsite and you’d need to modify every place you want to use that operation without a function pointer.

Well, this has been discussed dozens of times already. Essentially the example you constructed is specially crafted to make polymorphism look bad. If you want to do a simple calculator, the operation can be done in a single instruction and fits in register. For the types of code that OOP was designed, though, it has to search data structures which use memory allocated in the heap, fetch data from storage, invoke kernel syscalls, etc, and all of this will make the overhead of calling a vtable negligible. And even in the case that you find yourself in a situation where you need to have the CPU call an operation millions of times you could just dump the class structure with other code, translate it to C style opcodes and run this instead. This is what any numerical library in a virtualized language does, btw. And if you do your calculation in the methods it provides, instead of using the language directly, it's just as fast as C code. At the end of the day, the only performance penalty you cannot get away if when using higher level abstractions is the start up time it takes to initialize all the stuff, and a fixed amount of memory to store everything. I definitely think yoh could provide better content to your viewers than something which already has been exhaustively discussed in the 80's.

Nice video! There's a miss at 2:15: C++ classes are not C structures with function pointers. That's true only for polymorphic classes - and not even for all types of polymorphism, if we have to be picky. C++ classes are basically just structures, with member functions being normal functions with an implicit "this" argument. It's also worth mentioning the use of the "final" keyword can help assisting the compiler in optimising away virtual table lookups when virtual functions are called via the final implementation. Still, I prefer the C way as it doesn't add hidden data members and doesn't perform the shenanigans I described in this comment. Much easier to reason about.

An alternative title: "How C++ implements polymorphism and its cost"

Hence why devirtualization is a big subject for compilers, making this problem disappear when possible. Using sealed classes at the end of the inheritance chain helps for devirtualization.

Fun fact: doing all of that stuff in C is completely feasible, altough it's unconvenient (lots of boilerplate code is necessary, C just is not object oriented) and unsafe (you need to do type checking at runtime). I actually discovered these things on my own a few years ago, when I first began studying OOP and tried to replicate it in C, which was the only language I was familiar with at that time. When you actually implement this stuff, you realize how much wasteful it is. Btw, please note that there are many types of polymorphism. This is specifically what's known as inclusion polymorphism, which as far as I know is the only kind of polymorphism which has to be implemented with these type of runtime mechanisms. However, polymorphism is not something which is exclusive to OOP and stuff like adhoc polymorphism (ie function overloading or even traits in Rust) and parameter polymorphism (ie templates) are usually implemented statically. I know that there are a few other kinds of polymorphism, but I don't know much about those.

I appreciate how this is actually a technical look at HOW and WHY, rather than just says "this is slow and bad" Showing the ASM in an understandable way was really nice, and really helps to clarify whats really happening behind the scenes

This is a mood point: sure if your method contains only one line then yeah, it will be slower but if you write code like that, you either aren't a good coder or you are writing java ;)

To be fair to all those C++ code bases littered with virtual functions and interfaces: With C++ not having a clean way to define restrictions (SFINAE my ..) for generic/template parameters until C++20 (and I have not actually seen concepts used in any productive code base to this day..), it was often the easiest way to get at least somewhat sane compiler messages, even though static dispatch or an enum style solution would have been perfectly possible for a lot of these usecases. Rust (btw) does it kinda cleverly by combining dynamic and static dispatch into Traits, although using trait objects is somewhat frowned upon at times.

Thank you for awesome video!

I've never needed to use inheritance in C++, I can usually get everything done with single level classes

OOP is just a tool. It will be great if you know how to use it. PBRT use very much OOP a lot. It really difficult when I tried to port their code to Vulkan and GLSL, but then I realized why they choose to use OOP.

You can see how atoi is called in the loop to parse the second argument again and again ... I assume that's more operations than the virtual function

Function with the same signature in a derived class is not virtual by default in a base class as stated somwhere around 3:40. You need virtual keyword in a base class to enable dynamic polymorphism. It's not only for code readability.

It's the execution pipeline stall/flush/reload that burns the most CPU, not the vtable lookup. However, polymorphism can eliminate huge swaths of complexity in large programs when used appropriately. It's just a tool. Not a panacea

I'm reading a book about C++ written by Bjarne Stroustroup (the creator of C++) and he comments this about virtual functions: "The mechanism of calling virtual functions is almost as efficient as calling 'normal' functions (within 25%), so that efficiency questions shouldn't scare anybody off to use a virtual function, where a normal function call is efficient enough."

Is there any overhead to using classes without polymorphism in this case? I.e. if you had separate ADD/MUL classes without an Operation virtual execute function does it still perform much worse than the C code you used? I personally think the class structure looks cleaner and is easier to maintain so if you had to compromise somewhere in the middle between flexibility and performance it would be interesting to see if there is a middle ground. Thanks for the vid btw, always enjoy your uploads!

this video is an example of "the tool X is bad because I can use it wrong on purpose if I want!" reasoning. No C++ programmer would use polymorphism in a real world scenario like this. The best case scenario I can think of is someone saw an educational code sample which had to fit on a single screen, and thought that the example is the recommended usage, not just the syntax.

What about polymorphism without inheritance / virtual functions? Which is how polymorphism is usually used IRL.

Also good to note the performance impact of branch prediction misses. In normal code, the CPU is trying to predict whether a jump is going to happen, but it always knows the destination of the jump. With virtual functions the CPU knows that we will be jumping but it is trying predict the destination of the jump because the address is loaded from memory. When a branch destination is mispredicted, the CPU first needs to load the instructions for the correct branch, and only then it can start loading any data the instructions might require. The performance is also dependent on how predictable the function usage pattern is.

The real problem is actually the loss of a lot of function inlining opportunities. Even with a switch table, the compiler would be aware of the complete set of behaviors and can inline the function calls. The situation is even better with compile time polymorphism like with CRTP, which often produces the most optimized binary. But with a vtable the compiled binary has to remain compatible even with derived classes made later on that can arbitrarily overload the methods. Devirtualization can sometimes overcome this problem if classes are declared final, but it doesn't work that well and also coders often don't bother marking classes final.

This is the extreme example, your functions are so small that they hardly perform any work. You could even say "OMG THIS IS SO SLOWWWWW, you actually have to do context switching to call your functions that is really slow" This "performance drop" is hardly noticeable when your functions actually perform some work

I think the title is misleading: Polymorphism is more than just inheritance. A different type of polymorphism is using generics/having type arguments. In Rust, this complexity is resolved ("monomorphized") during compile time, removing the overhead that inheritance would have in this instance. Of course generics are pretty different to work with than virtual methods, but "polymorphism" was the chosen word. Another example could be using interfaces (dynamic dispatch) and traits, that can also be considered polymorphism and in certain languages (say, rust) also have no runtime overhead. A title that would be less of a problem in my opinion could be "why does inheritance suck for runtime performance?", or "why does inheritance suck?" for short.

just 2 hours before this video uploaded, i was watching 1 years old cppcon video on alternative for virtual method

I don't think overridden functions are virtual by default. Unless the specs have changed. If you override without using the virtual keyword, it only uses static analysis to determine with method to run. I.e. no v-table.

"C++ is just a bunch of compiler tricks" - old CS prof. There was a time where C++ was just another pre-processor to a C compiler. Most of the useful parts of C++ can be had in C by using an instance of the "object's" data as the first parameter to each of the "object's" methonds (functions).

this is purely theorical. in majority of real world programs, the actual function is so much more packed with memory lookups and operations that the single additional pointer dereference's effect on the final performance is insignificant. on the other hand you get a clean and maintainable code. weighing both sides of this scale, my choice personally would be rarely different. in other words, "polymorphism sucks" is very big claim to be fully settled with a 25% performance penalty on a function that has no parameter and does a simple mathematical operation.

This is not saying that C++ is slower than C. It's just that this is a great explanation of why hand coded switch statements can be faster than virtual functions, both of which you can do in C++ also. Virtual calls certainly need to be eliminated from performance critical areas of your code. In this use case I would use templates rather than virtual functions to achieve the same thing with probably better performance than the C code.

A single virtual call is essentially free, it's just a pointer indirection. It's when you have many many calls that you start to see the impact. With modern c++ you can use some template tricks to get rid of it at compile time in most cases

I once wrote a small C application for a friend using function pointers in structs just to troll them. Good times.

"I am building a small project by myself that performs a well-defined function. Here's why it's a Bad Idea to use a language designed for large projects with large teams that will be frequently modified to account for changes in the business landscape, using metrics appropriate to small solo projects of course"

In many cases the compile and resolve this if you turn on devirtualization optimizations. You can even provide better hints by finalizing your implementations. And even in non-optimized code the flexibility provided to the developer far out weights performance loss due to virtual table lookups even in extremely tight processing.

Not you but there seems to be a few people on the Internet who either hate OOP or are just obsessed with raw performance, and this is usually marked by the extensive use and emphasis of edge cases. In the real world getting working, maintainable code out of the door quickly is far, far more important. If it takes 0.2 seconds longer to execute then most of the time it simply doesn't matter. Good video though.

You can do OO in C just fine. You can put function pointers in structs and you can use named struct initializers like this: ``typedef struct { int (*Init)(MyObject* Object); int (*Free)(MyObject* Object); } MyClass;`` MyClass SomeSpecificClass = { .Init= DaConstructor, .Free= DaDestructor };

Does the additional store to memory used in the C++ version also not impact the runtime? That's 2 whole additional writes for the caller and 2 more reads for the callee. Especially on x64 where the calling convention uses registers for integers anyway, so if execute() took the two integers instead the difference between these might be even smaller.

The performance tradeoff for obeying "more readability by polymorphism" is just not worth it and there's a better perspective on the problem that can help you use other design patterns instead of polymorphism or switch cases.

This omits the fundamental advantage of polymorphism, which is that you can call methods on interfaces without knowing all the possible object types, and extend the application without recompiling. For example, you can have code that calls a method, and the object it is called on is provided by a shared library you load at runtime. The implementation may not even be written at the time that you write the code that uses the interface. This flexibility comes at a cost. Which is why code that doesn't provide this flexibility can run faster when that flexibility is not required. But try to provide that same flexibility in C, and you end up copying the same vtable mechanism C++ uses, only you have to do it manually instead of the compiler doing it for you. Polymorphism does not suck. It is a powerful tool, and as such it must be used with care. Learn when to use it, instead of overusing it or swearing it off completely.

I suppose you could always try to emulate how the C++ would implement vtables in C. The indirection will always be more slower compared to enum. edit: try godbolt next time

It would have been nice if you had said something about static dispatch and monomorphization, which languages like Rust do by default. For those that don't know, it creates a copy of you code for each type that you pass, so you get all the benefits of polymorphism without this runtime overhead.

The main performance problem with virtual functions is not indirect call but broken inliner pass in compiler. It would be great if author explained in new video what is inlining and devirtualization

I've actually written a lot of OO code in C. Depending on how you write it, it can be horrific or reasonably pleasant. When I first wrote my data structures library I implemented it in a somewhat generic way with loads of function pointers and size fields and type ID's in nearly everything. It was really easy to work with, but it kind of looked fugly. At some point I implemented some standard types to use as templates, and it was huge. Not that it ran particularly slow or anything, or produced bloated binaries, but it was a lot to maintain. For the second version I just said "fuck it" and implemented raw data copies and had the user provide a void pointer and a size. Let them figure it out.

3:40 did you mean function in derived class which have same signature and name as the one declared `virtual` in a base class? In derived class can omit `virtual` keyword but in base it is mandatory. Otherwise, you will overload but not override. Since C++11 best practice is to use keywords `override` and `final` which are written at the end of declaration. Function which does not have `virtual` keyword in base class is common method, not virtual. C++ does not have "virtual by default". And your comparison "fast C code" with "C++ slow code" is actually unfair. C++ developer could write same "C code" if needed. Polymorphysm (or other sorts of type erasure) is a tool which should be applied wisely. Ex. You are sure that two pointer dereferences are neglectably small compared to work done in those virtual functions. And your code is more maintanable with virtual actually. (Ex. end.)

I find it very interesting how classes in C++ basically work like they used to with babel before JavaScript had its native classes, where classes were transpiled to an implemetation used prototypes and a WeakMap.

In modern C++, one could use a concept for polymorphism, but in Rust switching between a v-table based dynamic polymorphic dispatch and a template based static dispatch is much easier, and with no wrappers.

I am a hobbiest programmer specializing in nlp. Classes and python are a godsend. The one thing holding me back usually is getting the code down and polymorphism and computionally heavy(as in needing more compute to compile and interpret) are way better for me because i am the bottleneck more than a computer. Also i cant run c code on google colab.

But but, polymorphism is so elegant in some cases

We can just use templates which can be used for compile time inheritance basically And with the addition of concepts it can be done without gouging your eyes out 😂

It's not always a possibility depending on the language and use case, but monomorphization can help a lot.

I think virtual functions should not be and frequently arent used in hot spots of the code, they are more proper to handle choosing different broad code paths (choosing between exporting to jpg vs png, serial console vs telnet)

I mean, that's just not what polymorphism is used for. There's no reason why the C code can't be used for the C++. And if you wanted to make it more C++ you'd make the functions templates. Still no need for a class. "This screwdriver is slow at cutting a 2x4" yeah well that's not what a screwdriver is for.

>it`s important to note that by default functions with the same signature in a derived class are virtual in the parent by default Is it means base class is becoming polymorphic when derived class overrides any its method (have at least one the same method signature) ? OR Derived class just hides base class methods and no vtables are created? I need confirmation 🙂

What happens if you declare the function arguments and also the operations themselves as const, which they should be, what happens then when you compile with optimizations ? Could you compare the assembly of both ? C++ might surprise you here ;)

I am tempted to write this in C not C++ as it can be, but as you pointed out, it would be ulgy, so maybe you can do a video on how to write a base class, a class that inherits a base class in C ... and the code looks (well it won't look pretty) at least readable? :D

To be fair, modern (youtube) talks I have watched almost always gravitate towards implementing polymorphism via template metaprogramming techniques, which in turn eliminates runtime dispatching and compile time optimizations, thus achieving max performance.

what if using in C an array of function pointers instead of switch-case-statement?

Do we get the same performance degradation if we use statically allocated 2D arrays? Because I think the vtables are exactly that - they are pre-computed. An interesting comparison would've been creating your own vtable-style arrays in C vs. C++ virtual functions. But yeah, polymorphism is very much overhyped. It does have some nice use cases, but I love the freedoms given by hybrid languages like C++ and python.

First (it is very painful not to post this when u see no comments)

wouldn't it be faster if the compiler just auto converted the function calls into an enum based check that directly calls the function? Or would the casting still be equivalent to a x20 perf loss?

Hey, I really love your videos but from one vim user to another, what is your colorscheme?

also, this is why monomorphization is the default behavior in rust

This video explains polymorphism quite well. I just do not like how it paints it as a massive performance hit. It is just a tool to be used when appropriate, yes it can be overused but so can any tool. When performance becomes a problem i can guarentee that it is probably not polymorphism eating your processing time.

soo . . . in C, you can do object-oriented programming, you merely do not get the syntax sugar.

dude...please tell me what font that is ur using in that neovim editor...i have been looking for it online cant find it...please I need help