3 ms·

> Is there a difference between c++ and java/go/etc if you enforce at code review for C++ to use only auto memory management like smart ptrs, containers, etc?

> Is there a difference between c++ and java/go/etc if you enforce at code review for C++ to use only auto memory management like smart ptrs, containers, etc? Smart pointers and containers are nowhere near memory safe, just enforcing their use gets you nowhere. `std::vector::operator[](size_t)` doesn't check bounds, `std::unique_ptr::operator*()` doesn't check null. > Imo the strong point of rust is compile error if you try to use an obj after move (unlike c++ with undef behavior The state of a value after being moved is defined by the move constructor. It is unspecified by the spec, but it's generally not undefined behavior.

Moldoteck 8mo ago
What you mean by smart ptrs not being memory safe? Vector access can be done with at method
- pjmlp 8mo ago
  Which unfortunately most people avoid using, and until C++26 there is no at() for span. The best is really to enable compiler specific hardening.
- ben-schaaf 8mo ago
  As I said, unique_ptr (or any of the others), do not check for null. So you can do this, and it will cause a segfault: std::unique_ptr<int> a; printf("%d\n", *a); Similarly unique_ptr::operator[] doesn't (and can't) do bounds checking, for example: std::unique_ptr<int[]> a = std::make_unique<int[]>(2); printf("%d\n", a[2]); There's also no attempt to limit the construction of invalid smart pointers, for example: int num; std::unique_ptr<int> a(&num); Smart pointers simplify memory management, and they're slightly harder to misuse than regular pointers, but they simply make no attempt at providing memory safety.
pjmlp 8mo ago
They do when using hardned runtimes configuration, which was compiler specific, and starting with C++26 is officially part of the standard. It naturally doesn't cover C style programming in C++.
- ben-schaaf 8mo ago
  The hardened runtime improves things, but it's still a far cry from memory safety. For example `std::vector::erase` has no hardened precondition. And of course the rest of the language around the stdlib is still entirely unsafe, not just the C parts.
  - pjmlp 8mo ago
    In theory, that will be taken care of with contracts and further revisions. In practice, it depends on how the contracts drama folds out. However I do agree it is still not quite there. Still, C++ isn't going anywhere anytime soon, so any improvement is welcomed, even rustc has to gain from it. I don't expect any RIR for GCC and LLVM happening any time soon, not only due to existing code, also due to all universities, and companies that contribute to upstream and aren't racing to adopt Rust.

Moldoteck 8mo ago

What you mean by smart ptrs not being memory safe? Vector access can be done with at method

pjmlp 8mo ago
Which unfortunately most people avoid using, and until C++26 there is no at() for span. The best is really to enable compiler specific hardening.
ben-schaaf 8mo ago
As I said, unique_ptr (or any of the others), do not check for null. So you can do this, and it will cause a segfault: std::unique_ptr<int> a; printf("%d\n", *a); Similarly unique_ptr::operator[] doesn't (and can't) do bounds checking, for example: std::unique_ptr<int[]> a = std::make_unique<int[]>(2); printf("%d\n", a[2]); There's also no attempt to limit the construction of invalid smart pointers, for example: int num; std::unique_ptr<int> a(&num); Smart pointers simplify memory management, and they're slightly harder to misuse than regular pointers, but they simply make no attempt at providing memory safety.

pjmlp 8mo ago

They do when using hardned runtimes configuration, which was compiler specific, and starting with C++26 is officially part of the standard. It naturally doesn't cover C style programming in C++.

ben-schaaf 8mo ago
The hardened runtime improves things, but it's still a far cry from memory safety. For example `std::vector::erase` has no hardened precondition. And of course the rest of the language around the stdlib is still entirely unsafe, not just the C parts.
- pjmlp 8mo ago
  In theory, that will be taken care of with contracts and further revisions. In practice, it depends on how the contracts drama folds out. However I do agree it is still not quite there. Still, C++ isn't going anywhere anytime soon, so any improvement is welcomed, even rustc has to gain from it. I don't expect any RIR for GCC and LLVM happening any time soon, not only due to existing code, also due to all universities, and companies that contribute to upstream and aren't racing to adopt Rust.