[deadcanard]

It's because shared_ptr uses an atomic count to synchronise between threads while the Rust version is assuming only one thread.

There is no equivalent in the standard C++ lib. Though it's very easy to write one. If you use gcc's libstdc++, the internal shared_ptr is actually templated on the lock policy so you can do something like: template<typename T> using nt_shared_ptr = std::__shared_ptr<T, __gnu_cxx::_S_single>;

Then if you use nt_shared_ptr instead, the code will be much simpler.

That said, your C++ code is incorrect as well. It gives the ownership to the shared ptr of a stack variable. During the destruction of the shared_ptr, delete will be called on a stack address leading to undefined behavior

[vinniefalco]

Boost has local_shared_ptr:

https://www.boost.org/doc/libs/1_65_0/libs/smart_ptr/doc/htm...

[codedokode]

You are right. First version of code actually used std::shared_ptr<Data>(new Data) (and produced similar code), but then I thought that it is unfair that we create a struct on a stack in Rust, so I changed the code. I should have used gcc with -Wall that detects the problem (clang doesn't).

[deadcanard]

Then, instantiate the smart pointer with a custom no-op deleter and if you use the nt typedef I mentioned above, you'll get a similar compiler output to Rust's.

e.g nt_shared_ptr<Data> x(&d, [](Data*) -> void{});

https://godbolt.org/z/d3qv4cE1v

[kccqzy]

It is a rookie mistake to wrap the result of new into a shared_ptr. It makes two heap allocations. You should use std::make_shared. It combines both and makes only one allocation.

[gumby]

Why call new? I work on a several hundred k code base that has a single call to new.