3 ms·

> Modern C++ doesn't really help. In fact, in my opinion, modern C++ tends to be less memory safe than "classic" C++, because it adds all sorts of new fun ways

by jupp0r 8y ago

> Modern C++ doesn't really help. In fact, in my opinion, modern C++ tends to be less memory safe than "classic" C++, because it adds all sorts of new fun ways to get use-after-free. I think modern C++ is much safer than legacy C++, not by disallowing the USE after free, but by giving you the tools to make sure that the FREE happens at an appropriate time. A lot of this is not necessarily a feature of the language itself, but of idioms the community seems to agree to ie CppCoreGuidelines. I'm thinking of - never use the delete operator manually, prefer std::unique_ptr - prefer single ownership over shared ownership - prefer immutable over mutable state - ... I agree with you that compared to Rust, this places a lot of burden on code reviewers and is in no way perfect, but I wouldn't say it's going in the wrong direction, making the language less safe.

pjmlp 8y ago
That is the thing though, I never did code reviews in C++ projects and have been often in the past (in my C and C++ days) the dude playing the D.Quixote role about static analysers. Modern C++ is safer, but only if you can ensure everyone on the team never reaches for C style tricks, nor the libraries that you link against.
pcwalton 8y ago
When people use the delete operator manually and mess up, do they usually delete objects too early or too late? In my experience, they usually delete objects too late or not at all (though I admit to not having hard data here). Accordingly, most of the benefits people cite regarding RAII classes such as unique_ptr are that they reduce memory leaks. I would agree that they do. But memory leaks aren't nearly as severe as use-after-free. Additionally, it's not really shared ownership that causes problems; it's the fact that references (and pointers) make it possible to violate ownership semantics. References are used all the time in C++, and you can't use any libraries without them. It doesn't matter if data has a single owner if that owner is deleted and you still hold references to the data. In fact, shared ownership via shared_ptr is safer than unique_ptr, from a UAF point of view.
- jupp0r 8y ago
  > Additionally, it's not really shared ownership that causes problems; it's the fact that references (and pointers) make it possible to violate ownership semantics. Shared ownership makes it much harder to reason about lifetimes, increasing the chance of mistakes. > shared ownership via shared_ptr is safer than unique_ptr, from a UAF point of view. Only if the dereferencing code holds the shared_ptr. It's also common to pass non-owning pointers to objects held by shared_ptr. > When people use the delete operator manually and mess up, do they usually delete objects too early or too late? As you pointed out, problems arise if objects are deleted too early or twice. Double free is common in C and can be exploited as well...
feanaro 8y ago
> I agree with you that compared to Rust, this places a lot of burden on code reviewers and is in no way perfect, but I wouldn't say it's going in the wrong direction, making the language less safe. Well if it isn't getting any safer than the time-disproven technique of relying on human behaviour and there are automatically safer alternatives, then it is less safe than those alternatives.
- jupp0r 8y ago
  Sure, but the argument was that newer C++ standards make the language less safe.

by jupp0r 8y ago

pjmlp 8y ago

That is the thing though, I never did code reviews in C++ projects and have been often in the past (in my C and C++ days) the dude playing the D.Quixote role about static analysers. Modern C++ is safer, but only if you can ensure everyone on the team never reaches for C style tricks, nor the libraries that you link against.

pcwalton 8y ago

When people use the delete operator manually and mess up, do they usually delete objects too early or too late? In my experience, they usually delete objects too late or not at all (though I admit to not having hard data here). Accordingly, most of the benefits people cite regarding RAII classes such as unique_ptr are that they reduce memory leaks. I would agree that they do. But memory leaks aren't nearly as severe as use-after-free. Additionally, it's not really shared ownership that causes problems; it's the fact that references (and pointers) make it possible to violate ownership semantics. References are used all the time in C++, and you can't use any libraries without them. It doesn't matter if data has a single owner if that owner is deleted and you still hold references to the data. In fact, shared ownership via shared_ptr is safer than unique_ptr, from a UAF point of view.

jupp0r 8y ago
> Additionally, it's not really shared ownership that causes problems; it's the fact that references (and pointers) make it possible to violate ownership semantics. Shared ownership makes it much harder to reason about lifetimes, increasing the chance of mistakes. > shared ownership via shared_ptr is safer than unique_ptr, from a UAF point of view. Only if the dereferencing code holds the shared_ptr. It's also common to pass non-owning pointers to objects held by shared_ptr. > When people use the delete operator manually and mess up, do they usually delete objects too early or too late? As you pointed out, problems arise if objects are deleted too early or twice. Double free is common in C and can be exploited as well...

feanaro 8y ago

> I agree with you that compared to Rust, this places a lot of burden on code reviewers and is in no way perfect, but I wouldn't say it's going in the wrong direction, making the language less safe. Well if it isn't getting any safer than the time-disproven technique of relying on human behaviour and there are automatically safer alternatives, then it is less safe than those alternatives.

jupp0r 8y ago
Sure, but the argument was that newer C++ standards make the language less safe.