top | item 47193334

(no title)

ben-schaaf | 1 day ago

> 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.

discuss

order

pjmlp|1 day 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|17 hours 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.

Moldoteck|1 day ago

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

ben-schaaf|17 hours 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|1 day 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.