Very concise and straight to the point, love it!

Im not sure about the "right" answer. Whatever that looks like. I do believe inheritance can get in the way of code reuse. I guess type erasure (external polymorphism) solves this. Whats you guy's approach to interface abstraction?

Interesting talk. I'm very curious if he's just mentioning the overhead of polymorphism because it's generally assumed, or if they were actually able to measure it. Because after watching kzread.info/dash/bejne/m2mBo7p6qNPFhNo.html , I'm more weary of just assuming virtual functions will be slower.

A lot of the data oriented design people who swear up and down how bad C++, abstraction, and object-oriented programming are, would probably end up implementing this with a struct that takes function pointers, and a static array of function pointers to switch between behaviors for different devices. You see this a lot in C code, and it's pretty clever. Unfortunately for them, it incurs the *exact same* "runtime overhead" as polymorphism does (in fact this is how polymorphism is implemented under the hood), except with none of the benefits. People always compare the "overhead" of an abstraction vs having code that does nothing, and never the overhead of the abstraction vs being forced to re-implement the same patterns without abstractions, the compiler, or the type system to help you.

@dat_21

28 күн бұрын

The idea behind data oriented design (or, a better name for it would be "performance oriented design") is to batch similar things together and process them in a way that is SIMD friendly and doesn't waste memory bandwidth by fully utilizing loaded cache lines. It doesn't have to do much with abstraction or polymorphism other than the fact that c++ compilers will NEVER rearrange or batch your data in classes to enable that kind of processing. Other thing to be aware of is that excessive abstraction of things makes finding strategies for performance design very hard. Often, one needs to dismantle lots of abstractions to get to the essence of what can be bundled together and what can't.

The Hardware/Communication/Robots example was too specific, thus hard to follow Nevertheless, I liked the talk! There are too few people telling you "it's fine to use the naive approach, unless you know you need something different "

Yes and c++ itself sucks now

Without numbers this talk was beyond useless. The conclusion was something we already knew and what you already stated in your intro "polymorphism has some overhead". Ok?? How much overhead? Did using "final" help? What was the point of this talk exactly?