3 ms·
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 s
by deadcanard 4y ago
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
- codedokode 4y agoYou 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 4y agoThen, 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 https://godbolt.org/z/d3qv4cE1v
- gumby 4y agoWhy call new? I work on a several hundred k code base that has a single call to new.
- kccqzy 4y agoIt 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.
- vinniefalco 4y agoBoost has local_shared_ptr: https://www.boost.org/doc/libs/1_65_0/libs/smart_ptr/doc/html/smart_ptr.html#local_shared_ptr https://www.boost.org/doc/libs/1_65_0/libs/smart_ptr/doc/htm...