why does inheritance suck?

C++ now has templates and this might be even faster than with C. At least you will need to make some effort. I prefer C but C++ has very powerful features (and very difficult).

polymorphism ( by inheretance or overloaded function calls ) is intended to reduce code duplication so that code is easier to maintain and read.
its not about speed which today is a non issue for most programs due to how fast even the slowest phones are.

But how does CPP compile the code

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

Not haven inheritance when you're used to sucks even worse. On my way to esp-idf due to inevitability "error: unknown type name ‘class’ gave me chills. my whole damn codebase of more than 15k line arduino-cpp went off scrolling down my inner vision... what a feeling.^^

I wonder if this is why sealed derived classes in C# have faster pattern matching performance.

This is a terrible example of inheritance and polymorphism. In addition to some of the concerns mentioned in other comments (especially @draconicepic4124), I have to wonder why you do not discuss static polymorphism, which does not rely on virtual methods (or a vtable) at all. See also: CRTP, templates, function overloading.

this kind of feels like C++ vs C, which I find kind of unfair to C++ nothing of the stl uses inheritance because of the reason you mention and modern C++ used inheritance rarely.

virtual calls are not that slow (also, theoretically, they can be resolved at compile time in most cases, because most cases don't really require polymorphism). however, objects have random memory layout and this seems to have at least as much of an effect on performance.
OOP sucks for one giant reason -- it entangles multiple things together:
* how polymorphism should work (functional dispatch can dispatch on multiple types and on values, and nobody should forget about good old HOF, function pointers in global variables and aliasing),
* how memory is laid out and managed (not that it's something bad, but it's slow, and this default could have been much better).
* how call signature looks, (an entirely made up problem, look at lisps, they have one type of expression, and it doesn't bother most users).
* how namespaces are organized (you should have namespaces/modules as separate entities from files or classes).
* it uses inheritance (even the name is bad), which assumes that objects have rigid hierarchy (another bad thing, someone very fond of aristocracy or oligarchy did the naming).

C++, Classes, OOP 🤮🤮

Virtual functions aren't used in cases where a switch-case is viable.

I wish you had more courses other than the basic course. I find myself knowing all the basics but get a little uneasy when it comes to structuring programs and when I work on bigger projects in the industry. A lot of programming gets hard when it is one big project. So many things happen at once other than small examples.
You should do a series where you work on an emulator or whatever from start to finish.

When you don't need bottle neck perf polymorphism can be a god send, but when you do, it's a curse from Satan.

I C what you did there ( ͡° ͜ʖ ͡°)

lol

Why is this always so hard for people to grasp. You mention inheritance and polymorphism and then evaluate it by comparing its runtime to another program. The entire point of inheritance isn't to improve performance and so evaluating it with that metric is moot. Inheritance and polymorphism exist to improve the maintainability of code. The entire point of OOP is to improve long term maintainability by making code more modular. I'm always seeing these types of videos trashing OOP but only doing so on performance evaluations. Get a job at a couple large companies that maintains large code bases, 1 with OOP and 1 without, then tell me which one was an easier place to work at.

One thing you missed is that it's not just the cost of doing the extra lookups (which in a loop would probably be in cache), but that it also makes the work of the CPU to predict where the branch will land very hard because there's a data dependency that could lead anywhere in memory. Modern CPUs have deep pipelines and rely on being able to guess what code will execute pretty well in order to run quickly. Vtables don't make that easy.

That said this is one of those things that can add up if it's used badly all over the place, but can also be very trivial if the virtual call itself isn't a significant amount of the work done. Tagged data or ADTs are efficient, but you shouldn't necessarily optimize for the highest performance code if the cost of a better design is relatively insignificant.

Function dispatch is a minuscule proportion of execution time in real-world code. If it actually is a factor, template specialisation and SFINAE will take care of almost all the overhead, while still allowing vastly better code organisation. And code correctness and maintainability beat small speed increases every time.

proud of u for being a neovim user.

I prefer c++ over c for several reasons, but I never use inheritance, 99.9% of the time you can write the same thing without it. I've never run into a problem (other than compile-time meta programming) where I HAD to use inheritance, I usually just use composition.

You keep conflating "objects" and "classes" in your videos. C has objects, what do you think an instance of a struct is? The conclusion of this video frustrates me, because junior developers watch stuff like this and just think "polymorphism bad, overhead bad". It should be clear that polymorphism isn't an issue in cases where you are not calling virtual methods on a hot-path where you need to shave off all latency, and even then, measure first and weigh out whether it REALLY matters. In the real world, it might be far more important for your application to support code extensibility via polymorphism or to use certain high level design patterns which rely on polymorphic code.

Nice video, but typedef on a struct is a bit of a NoNo (for various reasons)!

One thing I don't quite get: Can't the compiler determine the necessary function call at compile time?

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

I think one misconception is that object-oriented or procedural code is tied to a language. Part of it is the marketing of the languages. Ultimately, all code is compiled to ML even if it is through multiple layers it has to eventually be compiled to ML. No one will say that Assembly (which represents a 1 to 1 with ML) is object-oriented, but the object-oriented code is still implemented in Assembly (or ML). I can write code that is completely procedural is Java just by putting the entire contents of the code in static methods call by the static main function. The code is written in an object-oriented language and has at least one class; however, it is not object-oriented code. Same with C, I can package the data and functions together and use function pointers to create object-oriented code despite the fact that C is a procedural language. Object-oriented, procedural, functional, etc. are programming paradigms and languages can facilitate the use of one or more of those paradigms, but with the exception of a language that completely enforces the use of one of those paradigms (which C does not), they can be implemented using most of the languages out there.

To give my two cents about the subject here; Polymorphism does not suck. Let’s start it with that. It is slower, yes. So is 95% (or probably more but lets keep that for a margin) of the std library. Why would you use it? Because for most applications, that is not a concern. In fact, your software will probably even perform better with it, because the reality is that most people are not experienced enough to work around not using the tools you are given by a language and end up making mistakes (not errors) which end up slowing your program either way. A simple example is unnecessary copies. If you really need all the performance you can get, which again, there are only very rare cases for such applications, just use C and be done with it. Otherwise, use the tools the language for the job provides. It will give you a better application which is bound to be much less error prone than following the advice of this video. One last point I would like to add is that it is important to know the consequences of your actions, which this video demonstrates perfectly. Bearing that in mind, use the right tool for the job and think before you code. That said, still a nice video which explains in enough detail what happens, but unfortunately biased in a way that will not improve your decision making.

Convenience always comes with a cost. That's something one should be aware of. The benefits outweigh the costs most of the time though. That's why OOP-languages are popular.

I wonder how much of the overhead is due to using cout instead of printf

What if a language hardcoded the inherited functions into derived classes during compile time?
I assume there are clear downsides to this approach, so what if a language at least gave you the option?
Are there any languages that have tried this?

Yikes. If enum is short for enumeration, why is it being pronounced "e-num?" :)

I haven't used C++ in a while so excuse my ignorance: Is it possible to circumvent the vtable look up by calling add->execute() directly?

The greatest issue with these discussions on virtual functions is that most critics of given feature don't ask themselves why it was introduced in the first place. Most programming languages have similar mechanisms, not necessary OOP related. Functional languages allow to pass closures as arguments to function calls for example. Lets look at the C standard library qsort. It doesn't uses switch statements to determine how to compare elements of array. I believe author wouldn't be pleased, If he realized that std::sort of despised C++ is closer to his ideal that qsort of beloved C. Think a little about why qsort is such as it is. It will give you some understanding of why despite all costs of dynamic dispatching it still can be useful. If you wish to mention costs of dynamic dispatching please don't forget to mention benefts also. If you don't see them, please educate yourself on this topic.

why are you assigning values to the operands on every loop in c++, while in C, you don't?

What about speculative devirtalization?

Isn't ultimate point of OOP "ok, we sacrifice some speed and optimization of program itself for more abstract, less painful in writing code that can be put into production 10 times quicker"?
Cuz, you know, starting up a computer and writing some code to multiply 6 and 9 is slower than just take look at multiplication table, so computers are kind of pointless and ineffective

I recently rewrote a polymorphic class with a marked union because it was easier to use than the opaque base class. I expected it would be faster but 2x end-to-end speedup came as a surprise

After a while the code gets so hard that virtual calls are mandatory

This is dumb. Something being slower does not make it automatically sucky. Abstraction is good, and polymorphism is a way to achieve that. It's especially important for larger codebase, not a toy project like you did here.

you have no idea how upset i am that you did not do c function pointers in this comparison, this feels very apples to oranges when there was at least an orange-ish apple you could have used

Comments full of cpp cope. lmao

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 😂

what do you mean when you say that c does allow objects?
what do you get when you run command cc -c yourcode.c?

Man its almost like math doesn't need polymorphism and not a good use of it to begin with...

I appreciate the effort put in the video. But many mistakes....
C can be object oriented.
The function pointer in a structure is not gross, somehow verbose but ellegant.
Polimorphism is the key to flexibility, it does not suck.
If you need speed use plain C.
If you want your "code" faster and faster and FASTER, make a custom chip.

And believe me, once I was like you.

love your channel, I cant stop watching the video. Love you man

well, compared to Assembly, C++ can be seen as "slow" both in execution and compile time. However C++ mostly does the job just fine and performance sensitive apps like games or graphics renderers would probably benefit more from cleaner, effectient code, rather than Assembly language...