Posted by torutofu 20 hours ago
That link more comprehensively explains the rules too.
[Edit: Realized the end of the article explains this, the author began writing it months ago, likely before they read about the improved "dyn compatibility" naming]
> C++ doesn’t have this problem at all, since virtual dispatch always goes through pointers and return types are always pointers too.
Uh. C++ can return objects by value. Maybe it isn't idiomatic. And I don't know if there's a convenient spelling like `Self`. But it runs into the same problem, of course -- you would need to know the concrete value type returned to have storage for it.
And Rust has the ~same solution as imagined for C++ here, I think? Have a `DynClone` trait that returns `Box<dyn Trait>` instead of `Self`.
Stack-allocated objects and polymorphism only combine if the object is initialized as its true type and a pointer or reference to it is handed out. Obviously, this can create object lifetime issues if the pointer or reference escapes the lifetime of the stack frame containing the object.
If you have a value of the type itself (not a pointer or reference), then polymorphism doesn't even enter the equation in C++, even if you initialize from a derived type.
E.g. in this code:
Base b(m_catalog.makeDerived());
b.call_virt_func();
Runtime polymorphism is therefore only a game for pointers or references; it is the process of resolving the indirection that even allows for polymorphism to become a thing in C++. But this means that the compiler cannot know the actual type at compile-time for a polymorphic type, unless it can perform devirtualization as an optimization pass.
So although C++ will certainly allow you to define a class method that returns a virtual type by value (and not by pointer or reference), even for complex types, it is almost certainly a bug to do this unless you know for sure what the type will be statically, at compile time. Because the object you create as the return value will be forced to be the return type declared at compile time, "forgetting" the fact that it was created from a type deeper in the inheritance chain. This is the 'slicing problem' that was mentioned in the earlier comment.
This seems for me to be a major design flaw of Rust. It tries to repurpose traits for dynamic polymorphism, even if this doesn't fit perfectly. C++ is more honest, it has two separate mechanisms for static polymorphism (templates) and dynamic polymorphism (inheritance).
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.
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.
(About zero sized objects being the same)
But why does that mean the programmer never has to check? (or if they want that information from the borrow checker how would they get it?) It's not motivated as the intro above for c++ was just "In C++, we might do this to check if two pointers refer to the same object".
So the borrow checker knows already, why does that stop the programmer from wanting to know or separate these cases?
If you want to compare if two pointers point to the same place, you use https://doc.rust-lang.org/stable/std/ptr/fn.eq.html
Rust just defaults to value equality over reference equality. This is true for everything, not just ZSTs.
(I find the post's framing of "it's stored in the borrow checker" to be a bit odd, but I can't put my finger on exactly what it is. The borrow checker doesn't determine these sorts of semantics, it checks for liveliness and aliasing, so "do these pointers alias" isn't inherently not the borrow checker's job, it just strikes me as an odd way to put it. Maybe it's because you don't "ask the borrow checker for that information" really.)
> I find the post's framing of "it's stored in the borrow checker" to be a bit odd
That's exactly what I wanted to say as well.
I feel like it would have been better to just skip the borrow checker mention and just go "in rust this can not be done reliably ..(section about pointers being the same)"
Rust also has the complication that function pointers are not guaranteed to have an unique identity; If multiple functions compile to the same code, the compiler is allowed de-duplicate them.
The documentation [0] also warns it's also possible for the compiler to create multiple versions of the same function. And while I've absolutely seen the compiler to create multiple optimised versions of functions in disassembled code (partial inlining based on the caller), I'm not sure it's possible to get pointers to more than one version.
C++ actually did end up evolving the ability to define a zero-sized class without a unique memory address, but mostly to allow optimizations like the empty base optimization to apply in other situations where it could make sense, especially with templated or constexpr code.
Did it? Are you talking about the no_unique_address attribute (I had to go look that up because WG21 apparently doesn't care about consistently using or not using separators in attribute names) ? That attribute lets you do the same trick as empty base class but without the ceremony, however it doesn't let you make ZSTs.
By definition, a ZST hold no runtime data. It does hold some compile-time data based on its existence, but after compiling, that has been type erased away.
Since a ZST holds zero bits of state, there can only be one valid instance of it. You can't have multiple different versions of the same ZST representing different things.
So if you have one, you automatically know it's going to be equal to all other instances of the same ZST type. And not equal to any other ZSTs. There is no point doing a pointer comparison, as that gives you no extra information, type ownership is enough.
If you somehow need this property in your programs, I think you can just add a 1-byte member and use pointer equality. (I'm not a Rust expert.)
I guess maybe the semantics of ZSTs complicate the aliasing story a tad?