Using Modern C++ to Eliminate Virtual Functions - Jonathan Gopel - CppCon 2022

cpp people are working so hard to improve the language so much so, it is getting overwhelming ... "mental exercise" :)

This guy's name is Chad, not Jonathan

why after 2 slides they have to make it red black and arrows pointing here there, why not explain the concept in simple words?

Interestingly enough I implemented something almost identical to this (although not quite as clean) in my codebase before discovering this talk. I can vouch that, for my application (massively parallel fluid simulation), there were performance benefits over std::variant that made it worth it, and the implementation is nothing crazy.

- It is very convoluted and therefore error-prone
- It requires lot of boiler-plate
- You need to know all the types at compile time to create an instance e.g., "Foo<Foo1, Foo2, ...>". Virtual inheritance allows run-time selection e.g., Base *base = Base::New("Derived")

I 100% agree with the "bold statement" - you don't need to use virtual, you don't need to use smart pointers. I used that methodology in my c++20 order book project, which I talk about on my channel

in cases this presentation could substitute virtual, simple switch or even if will do the same i guess

Constructive criticism:
1) Use better code font and size
2) Don't clear your throat constantly in the microphone.
Otherwise thanks for the talk, very interesting.

Is the source code of this video released?

Could you please provide accurate subtitles for this video?

In the final code, is this a good example of using Concepts to avoid the use of CRTP for implementing static polymorphism (to enforce that concrete types implement a specific interface)?

For me, the only good use cases for virtual functions are: (1) having a container that can hold multiple implementations of the same base class and (2) decoupling implementations to have more unit-testable code. Variants or tuples of containers are sometimes a good alternative for case 1. However, there is no really good replacement for case 2. that does not involve some level of indirection.

Also, I should remind people here that the main cost of virtual functions is the fact that they are hard to inline. Their overhead is comparable to normal non-inlined functions, and usually, people mistake the overhead of virtual functions for the overhead incurred by the fact that they allocated their polymorphic objects on the heap.

How did we ended up making the syntax even more complex...

Meantime while CPP 20 becomes mainstream (10 years or so), we can use the CRTP (Curiously Recurring Template Pattern ) pattern that has been around for a long to create static interfaces, unless CPP 20 is covering something else that CRTP can not.

Virtual function performance is often dependent on the compiler to determine if a call is really virtual or not. But on mature CPUs you also have branch prediction, so a virtual function will have zero performance overhead if and only if the CPU can perfectly predict the destination address. On tiny embedded cpus that might be an issue. I agree that a programmer always have to consider if a virtual function is needed or not.

The sample code is completely unreadable. Why use such small fonts?
There's vast areas of white space to the left, right top and bottom. The margins are white, and the code is in dark theme. Unreadable.
What's the presenter thinking?

It is time to point out the very definition of self-centered stupid questions, that get asked way too frequently at CppCon presentations. These are always asked at an inappropriate time, derail the presenter from the topic they are trying to present, and asked at the expense (in terms of time wasted) of all attendees as well as the presenter, who is trying to finish their presentation within the time allotted. As is very often the case, these get asked (again and again) by the same self-centered "dum bass" haggler, who feels that it is appropriate to chime in with their personal views and/or questions related to something they are currently working on or having difficulty with (that no one else in the audience gives a damn about, but out of respect everyone has to bear these silently, rather than "flame and roast" the idiot asking the questions, for the greater good - for great justice):
1) Questions asked when the presenter just begins presenting a topic, fault finding the basic definitions and examples which are meant to be simple and may potentially be flawed, to allow for refinement and elucidation. These are often used to lay the foundation on which more complex topics can be constructed throughout the talk. The proper, if somewhat brash response, is along the lines of, "I just started describing the topic. May I continue, so that I can get to the answer to your question, which, as everyone in the audience clearly understands from the topic abstract I laid out at the beginning, will be covered by my presentation?"
2) Wasting everyone's time, mid-lecture, asking questions about fundamental well-defined C++ syntax and semantic constructs, even if novel, especially syntactic ones that can easily be googled, asked one-on-one, either in person at the end of the presentation (if possible) or via a followup email, or worst case, can be asked on Stack Overflow (if truly legitimate and not just an indication of laziness, ignorance, and delusions of, to coin a new phrase, self-importance - all other[ attendee]s be damned).

If you have tuple<vector<Ts>...> and need stable iteration, you can use tuple<vector<pair<INT, Ts>>...> where the INT in each pair represents the vector to look into next (this type INT needs to hold the number of vectors, i.e. needs not be size_t; for < 256 vectors, std::uint8_t is fine). The manager must keep track of the last vector (store 1 INT each) that was inserted into, so that its last value’s INT component can be updated when another element is inserted. It does not have to track the whole element, because insertion order in a vector is stable. When iterating, one must keep track of the next element in each vector.

I learned too much on concepts & the main subject. Thank🙏

If anyone who read this comment knows a reference to learn more about cpp concepts please let me know… (video or blog …)

Code font is too small and so much wasted space around it, unwatchable :(

Looking at this code makes me want to say, "C++ people, are you freaking kidding me?". C++ has become an overly complicated mess of a language, it has to go.

Great talk!

Why do you use
auto update() -> void {
and not
void update() {

?

Awesome sauce so proud of you!

Good presentation on concepts. BUT you don't need unique_ptr / shared_ptr to call virtual functions. They can be stack allocated a passed around as references. In that case with a final keyword it compiler will most likely devirtualize and you write simpler code. Also why would you define all other constructors/operators if you pass-around the type as a pointer/reference.

I would say :
1. You want to represent a value. Use variant for polymorphism when you need it.
2. You want to represent a API to achieve something go for virtuals ;)

I you design the API well the virtual call cost is negligible.

Thanks for the talk. Very interesting.

I would only use this when it has a significant impact on performance in an area where it matters. It looks quite convoluted. I'd pick it over SFINAE every day though 😝.

Unfortunately I couldn't read the text on the dark background so I stopped watching.

Great talk! A little peace of advice: Try to eliminate the ahs and ahms, otherwise great content.

it would have been good to have some data showing performance differences using this method. While I think the subject and talk is very interesting, I remain skeptical about the performance gains.

That tuple of vectors good idea but need to see in practice

great talk by a knowledgeable speaker. I found the colors on the slides difficult to make out however, until I was blowing my retinas out with the white background

Ok, I came to this because my daytime job is mostly Java, where every non-static method is virtual, and I was trying to see how this would work out. I have to admit our class hierarchies potentially grow deep and wide. It is a lot of behavioral inheritance with abstract methods as placeholders for different variations of behavior depending on where in the hierarchy you are. Somehow I fail to make the connection with this talk. I am guessing your usage of class hierarchies is simply to achieve different goals than we do. So far you seem to say that "if you don't need virtual you can get quite far without it" as well as "concepts can do neat things." That last one is definitely a takeaway for me...

The overusage of "foo" makes this hard to follow

Very good!

Nice option to virtual.

Great presentation.

std::variant is not enough, there are many use cases when it is inapplicable or ineffective such as huge difference between sizeof's, required incomplete type (variant needs to know all types when created while type erasure can be used for recursive types etc)
For example:
struct expression {
expression* a;
expression* b;
};
Its impossible to do with variant.
And yes, virutal functions is bad, but solutions exist already...(cant post links here =)))

A gigachad talk :)

Thanks, Gigachad.