Hacker News Reader

Comment by lachlan-sneff | Hacker News Reader

The rust std library doesn't hide allocations at all. It's very explicit.

I'm not even sure what Linus was referring to when he talked about memory allocations in C++ being hidden. Aren't the only options either an malloc (kmalloc) call or a `new` operator call?

I believe he was referring to encapsulation of allocations in constructors, and implicit invocations of the copy operator and constructor. He may have also been referring to a lot of how STL works, though the STL is pretty explicit about its allocations & behaviour.

Yeah, maybe he was referring to constructors. That might make sense, since something like "MyType t;" could allocate. I guess in the kernel context the STL (or whatever was around in 1992) would not be used though.

Edit: or even something like "a = b"

It's not constructors per se. It's what people put in to them. So MyType t also allocates in C, right (it'd be a stack allocation of sizeof(MyType) bytes)? But the difference is in C++ that could cause a bazillion heap allocations.

The problem gets magnified when you pass around these objects by value, thereby invoking copy constructors that also do those allocations, and doing value assignment, where you could have all those allocations happen again.

His comments predate r-value references, and a lot of stuff that r-value references have improved would be exactly the kinds of things where he saw a problem (though he'd hate the r-value solution).

I would think that overridable constructors and destructors are the alluded problem. Rust doesn't have the first and the later is slightly more constrained.

Reply on news.ycombinator.com