Let me try to identify which ones Rust catches:<p>&quot;#1: Using a shared pointer where an unique pointer suffices.&quot;<p>The Rust analog would be using Rc or Arc when Box is enough. Rust has the same problem.<p>&quot;#2: Not making resources&#x2F;objects shared by shared_ptr thread safe&quot;<p>Rust does NOT have this problem! You have to be explicit about which objects are thread safe (via Sync), and Rust will not allow you to transfer objects across threads without it.<p>&quot;#3 : Using auto_ptr&quot;<p>Naturally, Rust does not have this issue, which is strictly legacy C++.<p>&quot;#4 Not using make_shared to initialize a shared_ptr !&quot;<p>&quot;#5 Not assigning an object(raw pointer) to a shared_ptr as soon as it is created&quot;<p>&quot;#6 Deleting the raw pointer used by the shared_ptr&quot;<p>These are the same issue: in C++ you can construct a shared_ptr from an object you allocated with new; the reference count must then be allocated separately. Rust does not allow this, and avoids this issue, at the cost of some flexibility (like custom deallocators).<p>&quot;#7 Not using a custom deleter when using an array of pointers with a shared_ptr&quot;<p>AFAIK Rust doesn&#x27;t have this issue, because it doesn&#x27;t have C++&#x27;s array-decays-to-pointer semantics. In Rust the size of the array is part of the type; to be fair, this loses a bit of flexibility, but C++&#x27;s semantics here are insane, so point goes to Rust.<p>&quot;#8 Not avoiding cyclic references when using shared pointers !&quot;<p>Rust has this problem!<p>&quot;#9 Not deleting a raw pointer returned by unique_ptr.release() &quot;<p>Rust has an analog in Box::into_raw(), which is the same issue.<p>&quot;#10: Not using a expiry check when calling weak_ptr.lock()&quot;<p>Close one: Rust has the same issue, in that you can call rc::Weak::upgrade().unwrap(). unwrap() is often used with some impunity, especially with locks. However you do have to be explicit about your use of it, while in C++ it&#x27;s easier to forget. Let&#x27;s give this one to Rust.<p>Let me give one more point to C++:<p>&quot;#11: Accessing an object through a Rc&#x2F;Arc&#x2F;RefCell while a caller holds a mutable reference.&quot;<p>This is strictly a Rust problem: because there cannot be more than one extant mutable reference to an object, you have to be careful to not call out to something while holding a mutable reference. This is a doozy.<p>Total score: There are 7 unique to C++, 1 unique to Rust, and 3 that are shared.<p>Note that none of this has to do with the borrow checker! Indeed, the whole point of reference types like Arc&#x2F;Rc&#x2F;RefCell are when your lifetimes are dynamic, and you need to avoid the borrow checker, which assumes a statically knowable lifetime.