4 ms·

> if it's an implementation detail and well-tested The same can be said of C and C++, at which point, why does it matter if you use Rust?

by braveo 10y ago

humanrebar 10y ago
Rust has opt-out safety with 'unsafe' blocks. C++ doesn't even have opt-in safety. You can get fairly close with smart pointers and some other techniques, but 'fairly close' doesn't cut it when you're talking about memory corruption issues.
- AstralStorm 10y ago
  You can enforce safety by using the strict type system combined with polymorphic memory allocators in C++17, and get quite close to that with C++11. The only thing you cannot exactly prevent is "cast_dammit_cast".
  - dbaupp 10y ago
    Could you be specific about how the type system and polymorphic memory allocators defend against things like dangling references, iterator invalidation and use-after-free/move? I can't imagine an allocator affecting these unless it's one that just has a no-op free (which only use-after-free, anyway), nor is the type system strong enough by itself.
    - AstralStorm 10y ago
      1) If you cannot get a plain reference you cannot get dangling references. 2) Use data structures that keep iterators valid and modern reference counted internals. (so that when you have an iterator, you have the object) Alternatively copy on write semantics. 3) Use after move is relatively tricky if you want more. However, your allocator or data structure can catch it with specific implementation of move operators. Use after free can be reduced to use after move or caught with right delete/new operators. 4) Instead, you may have an API where you have your own high level reference-like type. There is a cost to it, same as in Rust. 5) What you cannot do is enforce people to use it always.
      - dbaupp 10y ago
        > There is a cost to it, same as in Rust All of these things have a larger cost than Rust: you're forced to use pervasive reference counting and very defensive data structures. Rust allows you to get away with pointers deep into other things, as well as aggressive data structures, all in safe code. Rust also has reliable use-after-move defense for arbitrary resources (not just vague dynamic protections for only the memory resource), and defends against data races. That is, Rust has true safety in a way that can give higher performance than approximate safety in C++.
  - deleted 10y ago
    [deleted]
  - pjmlp 10y ago
    Kind of, you cannot enforce your team mates, consultants and third party libraries that are part of the whole product to use them. Static analysers and code reviews are not always possible, depending on the target OS and compiler being used, or how the whole project across teams is organized.

> if it's an implementation detail and well-tested The same can be said of C and C++, at which point, why does it matter if you use Rust?

by braveo 10y ago

> if it's an implementation detail and well-tested The same can be said of C and C++, at which point, why does it matter if you use Rust?

humanrebar 10y ago

Rust has opt-out safety with 'unsafe' blocks. C++ doesn't even have opt-in safety. You can get fairly close with smart pointers and some other techniques, but 'fairly close' doesn't cut it when you're talking about memory corruption issues.

AstralStorm 10y ago
You can enforce safety by using the strict type system combined with polymorphic memory allocators in C++17, and get quite close to that with C++11. The only thing you cannot exactly prevent is "cast_dammit_cast".
- dbaupp 10y ago
  Could you be specific about how the type system and polymorphic memory allocators defend against things like dangling references, iterator invalidation and use-after-free/move? I can't imagine an allocator affecting these unless it's one that just has a no-op free (which only use-after-free, anyway), nor is the type system strong enough by itself.
  - AstralStorm 10y ago
    1) If you cannot get a plain reference you cannot get dangling references. 2) Use data structures that keep iterators valid and modern reference counted internals. (so that when you have an iterator, you have the object) Alternatively copy on write semantics. 3) Use after move is relatively tricky if you want more. However, your allocator or data structure can catch it with specific implementation of move operators. Use after free can be reduced to use after move or caught with right delete/new operators. 4) Instead, you may have an API where you have your own high level reference-like type. There is a cost to it, same as in Rust. 5) What you cannot do is enforce people to use it always.
    - dbaupp 10y ago
      > There is a cost to it, same as in Rust All of these things have a larger cost than Rust: you're forced to use pervasive reference counting and very defensive data structures. Rust allows you to get away with pointers deep into other things, as well as aggressive data structures, all in safe code. Rust also has reliable use-after-move defense for arbitrary resources (not just vague dynamic protections for only the memory resource), and defends against data races. That is, Rust has true safety in a way that can give higher performance than approximate safety in C++.
- deleted 10y ago
  [deleted]
- pjmlp 10y ago
  Kind of, you cannot enforce your team mates, consultants and third party libraries that are part of the whole product to use them. Static analysers and code reviews are not always possible, depending on the target OS and compiler being used, or how the whole project across teams is organized.