[CyberRabbi]

> If you're programming in C++, you probably do care about this level of performance, and in that case, it's nice to program in a style that guarantees it instead of hoping for a sufficiently smart compiler.

Neither implementation guarantees any particular sequence of assembly instructions. Both require hoping that a sufficiently smart compiler will compile it to a sufficiently optimal sequence of instructions.

[munificent]

Yes, in principle a compiler is free to generate arbitrarily horrendous code regardless of what you ask it to do.

In practice, non-virtual function calls are reliably compiled to fairly efficient code while virtual calls are much less reliable.

[CyberRabbi]

> In practice, non-virtual function calls are reliably compiled to fairly efficient code while virtual calls are much less reliable.

Like I said, this echoes the conventional wisdom that most C++ developers seem to retain. The compiler landscape has changed since that wisdom was formed, since the advent of LTO and devirtualization optimizations.

[asdfws]

So has programmer methodology. Throwing virtual calls everywhere is a relic of the past from the era of OOP fetishism. If you actually have statically verifiable leafs for virtual calls then you didn't even need a virtual call to begin with. It's code slop.

[i-use-nixos-btw]

Strongly agree on the philosophy - but alas my experience with this specific case has not been great.

I’ve seen it simplify patches of code here and there, and that does apply to the trivial examples given in the post this topic links to - a function call involving a known child class. But add some basic real-world complexity and it quickly gets too complex for the optimiser to prove that it knows for sure what child class it is dealing with.