2 ms·
Yeah, that has become largely a non-issue, all the alloc structure allow for fallible allocation now via a separated function call (and the old ones simply use
by zaarn 4y ago
Yeah, that has become largely a non-issue, all the alloc structure allow for fallible allocation now via a separated function call (and the old ones simply use the new one with an unwrap() call to panic on error).
Rust is entirely fine working with custom allocation stuff, there isn't any hidden allocator calls in you can make (well, the box operator, but that has been nightly forever and likely won't appear outside the stdlib ever).
- rascul 4y agoWhat is the box operator? This doesn't sound familiar to me, but I also don't use nightly.
- zaarn 4y agoThe box operator is basically how Box::new operates. One of the big problems if you were to DIY it, is to prevent stack allocation of heap data. The naive approach will result in your data first having to be allocated on the stack, passed to Box::new and then moved into the heap. The box operator allows moving the initialization of a datastructure into the heap entirely (and the compiler also auto-insert the malloc calls). It is largely a one-trick pony that only exists to help out the standard library, nobody should be using it ever. But it is the one instance where the rust compiler will deploy an allocation on the heap without any obvious way to tell that it did that.
- DrMeepster 4y agoBox operator isn't actually used in Box::new anymore. It's been replaced with a magic attribute, #[rustc_box]