Virtual functions are fine... the overhead that they incur negligible in most cases when you consider the benefits. That being said, like anything in C++ it can get out of hand - virtual functions are a tool, and should be used when they're needed and they fit your design pattern.

Virtual functions are the bedrock of modern, object-oriented C++, and are unlikely to be a significant performance bottleneck on today's relatively fast processors.

FWIW, the [font=courier new,courier,monospace]class[/font] is the bedrock of C++ OOP, and [font=courier new,courier,monospace]virtual[/font] is an add-on for the rare cases where you need runtime polymorphism.

Fast processors are one thing, but fast cache/RAM is another. Since C++ development started in the 80's, processors have speed up by over 10,000x, but RAM has only sped up by 10x, which means that relative to CPU speed, RAM is actually 1000x slower than it used to be!
If virtual is causing performance problems, it's unlikely to be because it's using too many CPU cycles -- it'll be because it's causing the CPU to sit idle for many cycles while it waits for RAM.

In my earlier example, both of these lines of code would end up calling the [font=courier new,courier,monospace]FooImplementation[/font] function, via the same mechanism that [font=courier new,courier,monospace]virtual[/font] uses:
X* object = ...;
object->Foo();
object->vtable->pfnFoo(object);We can see that the virtual call has 3 opportunities to generate a cache-miss:
object->vtable // read 4 bytes at address [object] into 'temp#1' (possible dCache miss)
->pfnFoo // read 4 bytes at address [temp#1] into 'temp#2' (possible dCache miss)
();// jump to instructions at address [temp#2] (possible iCache miss)Whereas a regualr function call has 1:
object->FooImplementation();// jump to instructions at address [X::FooImplementation] (possible iCache miss)This isn't getting any better over time -- as above, it's actually getting worse and worse (in relative terms -- cycles per cache-miss) as CPUs get faster!
So actually, it was fine to not worry about it decades ago, but it is a problem today.

If you're using C++, you probably care about performance (otherwise you should be using a less error-prone language, like C# or Lua or Python), and the biggest performance problem for modern C++ code is managing your memory access patterns to avoid cache misses. C++ gives you a lot of tools to achieve this goal, however, it gives you no control at all over the memory location of the [font=courier new,courier,monospace]vtable[/font] objects (equivalent of [font=courier new,courier,monospace]g_X_VTable[/font] in my previous post -- which can be manually organized in that hand-written virtual version), which makes virtual calls even less optimal.

For example, consider a pluggable image processing algorithm that needs to perform a certain operation per-pixel. We can provide a virtual function mutatePixel(Pixel p), which operates a pixel at a time, or we can provide a virtual function mutateImage(Pixel[][] p), which operates on the entire image. In the first case, we incur a virtual function call per-pixel (that's N^2 virtual function calls for an NxN image), and in the second we incur only a single virtual function call per image.
You can't just avoid virtual function calls entirely, but you can design them intelligently, with performance in mind.

That's an excellent point about how to amortize overheads.
A general case solution (to almost any problem) should operate on a range of objects at once (instead of using virtual to operate on only a single object).

Object Oriented languages imply the availability of virtual, as it allows for inheritance in addition to extension and aggregation...

Yeah, I just meant to imply that inheritance and polymorphism aren't the main/most-important/most-common parts of OOP, and are actually quite rare compared to, e.g. the use of composition or encapsulation.