3 ms·
"Rust basically just calls 'free' for you the moment something goes out of scope." C++ does that too with RAII. Go ahead and use whatever STL containers you li
by mikepurvis 1y ago
"Rust basically just calls 'free' for you the moment something goes out of scope."
C++ does that too with RAII. Go ahead and use whatever STL containers you like, emplace objects onto them, and everything will be safely single-owned with you never having to manually new or delete any of it.
The difference is that C++'s guarantees in this regard derive from a) a bunch of implementation magic that exists to hide the fact that those supposedly stack-allocated containers are in fact allocating heap objects behind your back, and b) you cooperating with the restrictions given in the API docs, agreeing not to hold pointers to the member objects or do weird things with casting. You can use scoped_ptr/unique_ptr but the whole time you'll be painfully aware of how it's been bolted onto the language later and whenever you want you can call get() on it for the "raw" underlying pointer and use it to shoot yourself in the foot.
Rust formalizes this protection and puts it into the compiler so that you're prevented from doing it "wrong".
- throwawaymaths 1y agothe tradeoff is that ~you have to guess where rust is doing the frees, and you might be wrong. in the end this would be strictly equivalent to an explicit instruction to free, with the compiler refusing to compile if the free location broke the rules. It's really too bad rust went the RAII route.
- swiftcoder 1y agoThere's no guessing - Rust has well defined drop order. It also has manual drop, should you wish to override the defined order.
- throwawaymaths 1y agosorry i shouldn't have said guess. i meant consider
- whyever 1y agoHow often do you care about the order in which objects are dropped?
- throwawaymaths 1y agoanything where you need to have stuff run in constant time.
- mikepurvis 1y agoIf you're in hard realtime land then you can't have any allocations at all; that's a pretty different ballgame. Destructors should be as simple and side-effect free as possible, with the exception of things like locks or file handles where the expectation is very clear that the object going out of scope will trigger a release action.
- imtringued 1y agoOkay, but an IDE could just visualize that for you. A linter rule could force you to manually drop if you want to be explicit.
- ShroudedNight 1y ago> a bunch of implementation magic that exists to hide the fact that those supposedly stack-allocated containers are in fact allocating heap objects behind your back The heap is but one source for allocator-backed memory. I've used pieces of stack for this, too. One could also use an entirely staticly sized and allocated array.