Re:Why Rust easily optimizes out smart pointers where C++ ca...
by vinniefalco on Sunday June 05, 2022 @05:23PM
(#31634977)
Boost has local_shared_ptr:
https://www.boost.org/doc/libs/1_65_0/libs/smart_ptr/doc/htm...
Re:Why Rust easily optimizes out smart pointers where C++ ca...
by codedokode on Saturday June 04, 2022 @09:21PM
(#31626969)
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).
Re:Why Rust easily optimizes out smart pointers where C++ ca...
by deadcanard on Saturday June 04, 2022 @09:27PM
(#31627009)
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{});
Re:Why Rust easily optimizes out smart pointers where C++ ca...
by kccqzy on Saturday June 04, 2022 @10:33PM
(#31627416)
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.
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