3 ms·

I heard that C/C++ game engine devs would throw everything on the stack and do their own thing in terms of memory management. How does this approach play with

• est31 7y ago
  You can do this in Rust as well, and it's in fact being done in the compiler: https://github.com/rust-lang/rust/search?p=2&q=TypedArena&unscoped_q=TypedArena https://github.com/rust-lang/rust/search?p=2&q=TypedArena&un... https://docs.rs/rustc-ap-arena/655.0.0/rustc_ap_arena/struct.TypedArena.html https://docs.rs/rustc-ap-arena/655.0.0/rustc_ap_arena/struct... In general, there is bad support in the standard for custom allocators, but there are crates that provide generic custom containers.
• jononor 7y ago
  No problem at all with using the stack a lot? But it would be explicit in most cases. Much less chances of memory corruption issues than in C/C++ thanks to lifetime tracking. And much less copying due to default move semantics, and the assurances given by lifetime tracking.
• m12k 7y ago
  Not a Rust dev, but from what I understand, the lifetime tracking of Rust means you can safely give out references to stack allocated memory without worrying about corruption/segfaults/use-after-free errors or the like, because the compiler will catch it if that is possible, whereas in C++ you'd usually want to do defensive copying in situations like that. So in some cases, Rust actually allows you to fearlessly do things the most efficient way in a way you'd not be able to do in C++.