Hacker News Reader

Comment by Panzerschrek | Hacker News Reader

> you can choose at use site

This is possible in C++ too, but it may require extra work. But is it really needed that often to use both kinds of polymorphism for the same type?

> the size of the objects do not pay for dynamic dispatch because the vtable pointer is kept together with the object pointer, not within the object.

You have identical memory overhead in Rust and C++ if you store a single pointer to a polymorphic object. But if more than one such pointer is stored (if it's shared), Rust uses more memory, since it stores N virtual table pointers (together with each object pointer), where C++ stores exactly one virtual table pointer within the object itself.

View on HN

> This is possible in C++ too, but it may require extra work.

Everything is possible, what matters is how much work you have to do to achieve and maintain it.

> You have identical memory overhead in Rust and C++ if you store a single pointer to a polymorphic object. But if more than one such pointer is stored (if it's shared), Rust uses more memory, since it stores N virtual table pointers (together with each object pointer), where C++ stores exactly one virtual table pointer within the object itself.

On the other hand Rust uses less memory if you store 0 polymorphic pointers, while C++ still pays the cost of storing a vtable pointer for each object instance.

Effectively C++ choose a design that optimizes for having a lot of polymorphic pointers, while Rust optimized for supporting polymorphism for all objects at no extra cost if you don't use it.

The C++ design is optimised for the case where you're mostly storing Things everywhere and then at runtime code works out whether each particular Thing is a Customer, or a Product, or a Target, or an Artist, or what...

I don't think even an LLM writes software like this, maybe somebody's Java 101 class teaches this, but frankly I think that's a bad way to teach even Java.

The Rust approach optimises for cases where Customers and Products and Targets and Artists are stored and treated separately and if we do need the generic Thing somewhere it's pretty rare so we store the extra information only where needed.

There is another important reason not to store the vtable pointer in the object: performance! In C++ if you want to make a virtual method call you have a double indirection where you must first load the object and only then can you load the vtable. Having a fat pointer like Rust does means that both loads can be in flight at once. If you are using enough dyn references to care about the extra memory then you'll likely care about the performance impact of those extra indirections even more.

Reply on news.ycombinator.com