3 ms·
Smart pointers and vastly more type safety is not a safety net?
by jeremyjh 8y ago
Smart pointers and vastly more type safety is not a safety net?
- fao_ 8y agoCan a turing-complete type system be sanely considered safe?
- dbaupp 8y agoTuring completeness of the type system isn't what causes C++'s unsafety: in a sense, being turing complete theoretically allows encoding more safety into the type system. It also allows encoding more impossible-to-write-a-program into the type system, but that's orthogonal (plus, if you can't compile anything, you can't run anything unsafe!). C++ improves on C in some respects, but still suffers from undefined behaviours like use-after-free/dangling references, dereferencing of null (e.g. a moved-from unique_ptr) and iterator invalidation, none of which are caused by a Turing complete type system (they all, in various forms, exist in C too).
- vvanders 8y agoHaving used smart pointers extensively in C++ I'd much rather debug a malloc/free issue. Finding cylces is not trivial or quick.
- winter_blue 8y agoYou’d rather debug malloc/free than try to find and eliminate shared_ptr cycles? You really think that’s easier? Besides, you shouldn’t be using shared_ptr much at all, and should try to use unique_ptr everywhere.
- vvanders 8y agoYup. Most of the debug CRTs contain fantastic malloc/free debugging and pointer overwrite tools. FWIW I don't consider unique_ptr a smart pointer, that's just RAII in action.
- floatboth 8y agoIt's not a very good safety net when it's completely optional. Sure, it's technically optional in Rust too, but in Rust, you have to wrap raw pointer dereferences and stuff into unsafe{} blocks. The default is safety. In C++, your whole program is an unsafe block.