4 ms·
I have almost the exact inverse view: when I write C++ code, I shed a tear if I can't disable exceptions and use something very analogous to Rust's Result type.
by sidlls 10y ago
I have almost the exact inverse view: when I write C++ code, I shed a tear if I can't disable exceptions and use something very analogous to Rust's Result type. I can't tell you how many times I've written some version of 'class Result<T> { union {int, T} }' (obviously, that's illustrative, given all the extra work that has to go into writing a proper tagged-union in C++) for use with C++ code at jobs I've had in the past. Rust's implementation here is great, in my opinion.
- lacampbell 10y agoAs an aside: I'm curious as to why you'd implement a Result type in C++ as a tagged union where you have to manually branch on the tag, and not as an abstract class with two children.
- sidlls 10y agoI find it easier to reason about.
- lacampbell 10y agoInteresting. I tend to view ADT as syntax sugar for a shallow class hierarchy of small immutable objects with no encapsulation or behaviour.
- dbaupp 10y agoThe union avoids requiring an allocation for, say, returning a Result.
- lacampbell 10y agoI am not sure what using an object vs using a struct with an enum + a union has to do with allocation. My C++ is rusty (no pun intended).
- deleted 10y ago[deleted]
- dbaupp 10y agoThe equivalent of a function returning Result<T, E> in Rust would be returning something like unique_ptr<ResultBaseClass<T,E>> because the two subclasses have different sizes and thus can't be returned directly (or else one will be object slicing). The struct version stores everything inline from the start (it has a single static size) and so can be returned without needing a pointer.
- lacampbell 10y agoMy C++ skills have atrophied worse than i thought - I completely forgot you can't return an abstract class by value.
- softc 10y agoJust to clarify, In this specific case, I think we're talking about interface, not implementation. Your preference is fair, since interface is a subjective issue. Personally, I find it more convenient to simply assume all code can encounter a error. Given that assumption, I find it redundant to add extra syntax to fail on unhandled errors.