5 ms·

One thing I love about Rust is that allocation are very explicit and easily spotted which helps a lot when one wants to avoid them. I found C++ to be treachero

One thing I love about Rust is that allocation are very explicit and easily spotted which helps a lot when one wants to avoid them. I found C++ to be treacherous around corners cases on this subject.

pjmlp 6y ago
Unless you are going to review the whole code, written from scratch, there is no way to actually be aware of all allocations in Rust without help from a memory profiler.
- cogman10 6y ago
  I think the point was more that allocations are fairly explicit. There are a few places in C++ where allocation can happen pretty much invisibly. A copy constructor is an example of that. You might see a new allocation simply by calling a method. With rust, you usually won't see an allocation unless it is explicitly called for. You can follow the call tree and very easily pick out when those allocations are happening.
  - pjmlp 6y ago
    Rust also has operator overloading and implicit conversations, both can cause memory allocations.
    - cogman10 6y ago
      Certainly. However, both of those things (from what I've seen) are fairly rare. The C++ copy constructor comes up fairly frequently.
      - pjmlp 6y ago
        Like unsafe Rust code, there is the theory and then there are the code bases that one finds out in the wild on crates.io and in-house, not necessarily using best practices.
    - dthul 6y ago
      Rust does not have implicit type conversions.
      - pjmlp 6y ago
        Via Deref.
        dthul 6y ago
        Not in practice. It's only used for reference coercions to existing objects. You would need to ignore the documentation and bend over backwards to use it for an actual type conversion, because you can only return references.
        pjmlp 6y ago
        Bending backwards is a synonym to code quality delivered by consulting/offshoring projects across most big corporations.
- dthul 6y ago
  Just one or two days ago I asked here on HN how memory allocations in C++ are considered to be more hidden than in Rust and got some good replies: Especially constructors, copy constructors, assignment operators etc. can introduce non-obvious allocations. For example: T t; a = b; T t2 = t; can all allocate in C++. The equivalent in Rust: let t: T; // won't allocate let t = T::new(); // might allocate a = b; // won't allocate let t2 = t; // won't allocate let t2 = t.clone(); // might allocate So in Rust you can tell that as long as there is no function call, there won't be an allocation.
  - pjmlp 6y ago
    Like operator overloading and implicit conversations.
    - dthul 6y ago
      True, those are even more places where C++ can implicitly allocate. The operator overloading also applies to Rust. Rust has no implicit conversions though, which are arguably worse since they are invisible (that's why I usually mark all my expensive single argument constructors as "explicit").
      - pjmlp 6y ago
        Sure it has, you cannot ensure Deref implementations don't allocate.
        dthul 6y ago
        While technically true, the documentation makes it very clear that Deref should only be implemented for smart pointers and never fail. So no allocations in practice.
        pjmlp 6y ago
        Ah problem solved then, we just need to document very clear that C code should not corrupt memory, how did I never thought of it.
Matthias247 6y ago
I actually don't think so. I've seen plenty of Rust libraries that copy strings about 5 times unnecesssarily between usages, just because `.clone()`, substrings and co are so convenient. Those all could have been optimized away, but the authors of that code didn't knew or didn't try. And if you do `MyAwesomeStructure::new()` you might actually trigger a whole bunch of allocations which are invisible. So a "yes" from my side on Rusts ability to remove allocations if you try hard enough. A "no" however on allocations being extremely explicit and easy to see for non experts.
- nestorD 6y ago
  dthul's comment [0] covers my point of view fairly well. Clones and new are easy to spot, you might not be careful about them because you do not care or have other priority but you can find/grep them quickly: they are explicit. Meanwhile C++ has a lot of implicit memory allocation and things that might or might not allocate. [0]: https://news.ycombinator.com/item?id=24061235 https://news.ycombinator.com/item?id=24061235

One thing I love about Rust is that allocation are very explicit and easily spotted which helps a lot when one wants to avoid them. I found C++ to be treacherous around corners cases on this subject.

pjmlp 6y ago

Unless you are going to review the whole code, written from scratch, there is no way to actually be aware of all allocations in Rust without help from a memory profiler.

cogman10 6y ago
I think the point was more that allocations are fairly explicit. There are a few places in C++ where allocation can happen pretty much invisibly. A copy constructor is an example of that. You might see a new allocation simply by calling a method. With rust, you usually won't see an allocation unless it is explicitly called for. You can follow the call tree and very easily pick out when those allocations are happening.
- pjmlp 6y ago
  Rust also has operator overloading and implicit conversations, both can cause memory allocations.
  - cogman10 6y ago
    Certainly. However, both of those things (from what I've seen) are fairly rare. The C++ copy constructor comes up fairly frequently.
    - pjmlp 6y ago
      Like unsafe Rust code, there is the theory and then there are the code bases that one finds out in the wild on crates.io and in-house, not necessarily using best practices.
  - dthul 6y ago
    Rust does not have implicit type conversions.
    - pjmlp 6y ago
      Via Deref.
      - dthul 6y ago
        Not in practice. It's only used for reference coercions to existing objects. You would need to ignore the documentation and bend over backwards to use it for an actual type conversion, because you can only return references.
        pjmlp 6y ago
        Bending backwards is a synonym to code quality delivered by consulting/offshoring projects across most big corporations.
dthul 6y ago
Just one or two days ago I asked here on HN how memory allocations in C++ are considered to be more hidden than in Rust and got some good replies: Especially constructors, copy constructors, assignment operators etc. can introduce non-obvious allocations. For example: T t; a = b; T t2 = t; can all allocate in C++. The equivalent in Rust: let t: T; // won't allocate let t = T::new(); // might allocate a = b; // won't allocate let t2 = t; // won't allocate let t2 = t.clone(); // might allocate So in Rust you can tell that as long as there is no function call, there won't be an allocation.
- pjmlp 6y ago
  Like operator overloading and implicit conversations.
  - dthul 6y ago
    True, those are even more places where C++ can implicitly allocate. The operator overloading also applies to Rust. Rust has no implicit conversions though, which are arguably worse since they are invisible (that's why I usually mark all my expensive single argument constructors as "explicit").
    - pjmlp 6y ago
      Sure it has, you cannot ensure Deref implementations don't allocate.
      - dthul 6y ago
        While technically true, the documentation makes it very clear that Deref should only be implemented for smart pointers and never fail. So no allocations in practice.
        pjmlp 6y ago
        Ah problem solved then, we just need to document very clear that C code should not corrupt memory, how did I never thought of it.

Matthias247 6y ago

I actually don't think so. I've seen plenty of Rust libraries that copy strings about 5 times unnecesssarily between usages, just because `.clone()`, substrings and co are so convenient. Those all could have been optimized away, but the authors of that code didn't knew or didn't try. And if you do `MyAwesomeStructure::new()` you might actually trigger a whole bunch of allocations which are invisible. So a "yes" from my side on Rusts ability to remove allocations if you try hard enough. A "no" however on allocations being extremely explicit and easy to see for non experts.

nestorD 6y ago
dthul's comment [0] covers my point of view fairly well. Clones and new are easy to spot, you might not be careful about them because you do not care or have other priority but you can find/grep them quickly: they are explicit. Meanwhile C++ has a lot of implicit memory allocation and things that might or might not allocate. [0]: https://news.ycombinator.com/item?id=24061235 https://news.ycombinator.com/item?id=24061235