> I sometimes feel C and C++ were very clear on where data lives (stack vs heap) and how it’s organized (struct alignment), while Rust seems a little more opaque . I’ve felt a similar way working in Go.
This is interesting to me. I fully agree about this with Go (and in the past I've sometimes seen this make optimizations difficult as in practice it's hard to keep track of heap allocations other than runtime inspection), but I feel like Rust is actually better at C++ than this. Alignment is certainly a different beast, as by default I don't think you can really assume anything about how Rust will lay out a struct (with the workarounds being various `repr` attributes), but in terms of heap allocations, I'd argue there isn't anything as ambiguous as a raw C++ pointer. If you're able to get away with smart pointers all of the time, I could see this being less of an issue, but from my somewhat limited experience with C++ there seem to often be cases where APIs still expect raw pointers from time to time, so I wouldn't expect to be able to look at some random function call in a call graph and know what type of memory it's dealing with in the absence of documentation or runtime inspection.
In Rust, it's a `Box<T>`, `Rc<T>`, `Arc<T>`, `Vec<T>`, or `String`, it's on the heap. If it's not, chances are it's on the stack. There are separate types for the non-owning versions of those types for references (`&T`), slices (`&[T]`), and string references (`&str)`, none of which require heap allocations to create (although they might indirectly refer to heap-allocated data in one of the other types mentioned before). There are probably other types that one might run into that are heap-allocated, but even when dealing with something like indirection from dynamic dispatch, any heap allocations needed to make things work will end up being explicit via something like `Box` or `Arc`. I might just be misunderstanding the point being made here; maybe the author was looking for documentation rather than relying on the types themselves, or maybe they had reason to be concerned about whether the type behind a reference or slice happened to be heap allocated or not, but in my experience, only needing to care about that in the context of when explicitly making a new allocation is a benefit, not a drawback.
In C++, in particular when restricting to a C like subset, I prefer looking at an expression like
foo->bar.baz
instead of (in Rust and other modern languages that decided to get rid of the distinction)
foo.bar.baz
For example, the former lets me easily see that I can copy foo->bar and I now have a copy of baz (and indeed bar). In a newer language, it's harder to see whether we are copying a value or a reference.
OP here - thank you for your explanations! My writing got a little messy in this section, but I think my intended focus here was on struct alignment. I've only had to care about alignment in some very niche cases dealing with C, so I don't think it's something that'll come up in my typical non-high performance software work. I agree that `repr` would likely be the way to go.
I do appreciate that the act of copying or allocating something nontrivial in Rust requires verbosity. Your list of typical heap containers is great and I'll do my best to internalize that. I'd just add that some primitives like sync::Mutex [1] in Rust's standard library (which to my knowledge don't exist in the same flavor in C++'s STL) require some additional gymnastics to wrap my head around. The wrapper is super useful though :)
Is the following accurate? “If a type has a generic bound T: ?Sized, then its data lives on the heap.” (Except for &T because it's the one type that doesn't take ownership of its T upon construction.)
saghm|2 months ago
This is interesting to me. I fully agree about this with Go (and in the past I've sometimes seen this make optimizations difficult as in practice it's hard to keep track of heap allocations other than runtime inspection), but I feel like Rust is actually better at C++ than this. Alignment is certainly a different beast, as by default I don't think you can really assume anything about how Rust will lay out a struct (with the workarounds being various `repr` attributes), but in terms of heap allocations, I'd argue there isn't anything as ambiguous as a raw C++ pointer. If you're able to get away with smart pointers all of the time, I could see this being less of an issue, but from my somewhat limited experience with C++ there seem to often be cases where APIs still expect raw pointers from time to time, so I wouldn't expect to be able to look at some random function call in a call graph and know what type of memory it's dealing with in the absence of documentation or runtime inspection.
In Rust, it's a `Box<T>`, `Rc<T>`, `Arc<T>`, `Vec<T>`, or `String`, it's on the heap. If it's not, chances are it's on the stack. There are separate types for the non-owning versions of those types for references (`&T`), slices (`&[T]`), and string references (`&str)`, none of which require heap allocations to create (although they might indirectly refer to heap-allocated data in one of the other types mentioned before). There are probably other types that one might run into that are heap-allocated, but even when dealing with something like indirection from dynamic dispatch, any heap allocations needed to make things work will end up being explicit via something like `Box` or `Arc`. I might just be misunderstanding the point being made here; maybe the author was looking for documentation rather than relying on the types themselves, or maybe they had reason to be concerned about whether the type behind a reference or slice happened to be heap allocated or not, but in my experience, only needing to care about that in the context of when explicitly making a new allocation is a benefit, not a drawback.
jstimpfle|2 months ago
quadrophenia|2 months ago
I do appreciate that the act of copying or allocating something nontrivial in Rust requires verbosity. Your list of typical heap containers is great and I'll do my best to internalize that. I'd just add that some primitives like sync::Mutex [1] in Rust's standard library (which to my knowledge don't exist in the same flavor in C++'s STL) require some additional gymnastics to wrap my head around. The wrapper is super useful though :)
[1] https://doc.rust-lang.org/std/sync/struct.Mutex.html
bobbylarrybobby|2 months ago
epage|2 months ago
Would love built in coverage support but investigation is needed on the design (https://github.com/rust-lang/cargo/issues/13040) and we likely need to redo how we handle doctests (https://blog.rust-lang.org/inside-rust/2025/10/01/this-devel...).
quadrophenia|2 months ago
justatdotin|2 months ago
dionian|2 months ago