Why Rust easily optimizes out smart pointers where C++ cannot?

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).

[ Parent | on HN ]

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{});

https://godbolt.org/z/d3qv4cE1v

[ Parent | on HN ]

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.

[ Parent | on HN ]

Re:Why Rust easily optimizes out smart pointers where C++ ca... by gumby on Saturday June 04, 2022 @10:24PM (#31627345)

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

[ Parent | on HN ]