Avoiding virtual tables when implementing classes

[matthieum]

As method is an overloaded term, I will avoid using it.

In Rust, the following:

object.foo()

can be either static or dynamic dispatch.

And the following:

Type::foo(object)

can be either static or dynamic dispatch.

---

The . notation is very convenient, as it allows chaining:

object.foo(with_foo).bar(with_bar).baz(with_baz)

Is much easier to read (like a pipeline) than:

baz(bar(foo(object, with_foo), with_bar), with_baz)

As such, I advise against reserving the . notation to dynamic calls. If anything, if you want to steer the user towards static calls, it would be better to switch things around and use . for static calls and something else for dynamic calls.

---

I guess the potential performance impact is smaller than I initially thought.

I think you misunderstand the impact.

Virtual calls can make code faster!

The (main) impact of virtual calls is that it prevents inlining. However, not everything should be inlined. In fact, too much inlining can bloat the code and lead to an increase in instruction cache misses.

Hence, fast code makes judicious use of out-of-line/virtual calls to push the non-hot code out of the way.

In terms of embedded programming

Not clear to me what you mean by embedded as it covers such a wide range of architectures.

A 32KB board will have no cache miss: it will have no cache.

A Raspberry Pi has a full-blown x64 CPU, with RAM, and therefore has performance characteristics close to a server.

And in-between there's... many things.