8 ms·
> since C++11 there is no reason for not using smart pointers There are many reasons for not using smart pointers, first amongst them for me being performance.
by steeleduncan 4y ago
> since C++11 there is no reason for not using smart pointers
There are many reasons for not using smart pointers, first amongst them for me being performance.
Smart pointers do allow you to remove a large class of memory bugs from your code (albeit not memory leaks) in the same way that Rust's safe references do. However C++ smart pointers impose a run time performance penalty on your code, whereas in Rust the checks happen at compile time leading to better runtime performance.
- gpderetta 4y agoWhat's the overhead of an unique_ptr vs the equivalent rust pointer (yes yes, I know that the Itanium ABI has non optimal calling convention for unique ptrs, but I would be surprised if you can measure it)?
- deleted 4y ago[deleted]
- hdhrufjdi 4y agoJust a thought: null pointer check before deallocation
- gpderetta 4y agodelete of a null pointer is well defined.
- menaerus 4y agoAside from you being completely uninformed because free(nullptr) or, for that matter, delete nullptr does absolutely nothing and is well defined operation so you don't need to check for that condition in the first place. But even if you had to, what implications would it have, if you care to explain?
- hdhrufjdi 4y agoThe implications would be checking if it is null before performing the deallocation of the memory, which is a runtime overhead. Stack overflow says "delete" would check for null before deallocation: https://stackoverflow.com/questions/4190703/is-it-safe-to-delete-a-null-pointer https://stackoverflow.com/questions/4190703/is-it-safe-to-de... Happy to be educated
- menaerus 4y agoExtra branch which is going to be taken 99.99999% of the time is not going to present any runtime overhead. CPU BP unit handles it for us. That said, if this really had been an overhead, virtually every language out there would suffer from it, including Rust. Every language out there at some point needs to call into the libc.
- hdhrufjdi 4y agoA bit of research revealed that you don't have to call into libc. You may use alternatives or even use sys calls directly, like Go apparently did: https://stackoverflow.com/questions/41720090/does-go-depend-on-c-runtime https://stackoverflow.com/questions/41720090/does-go-depend-... PS: small overhead is technically still overhead; yet, I am not saying you should worry about it
- menaerus 4y agoYes, you can write your own runtime ... which will have to rely on the OS internals to do any meaningful work, and in case of memory allocation or deallocation it will have to rely on brk/mmap and then you will be back to square one. Overhead is almost purely theoretical and it cannot be avoided and is not anything common or specific to unique_ptr's.
- hdhrufjdi 4y agoRust could avoid it through the Box abstraction that afaik assumes not having a nullptr
- foxhill 4y ago> However C++ smart pointers impose a run time performance penalty on your code. i'm not sure if this is the case. unique_ptr doesn't really do much other than use the type system to ensure that only one instance of the pointed-to value exists at once. as far as i understand, it doesn't strictly do anything at runtime.
- simiones 4y agoI'm honestly not sure: can unique_ptr<T> be used in place of a T* pointing to a stack-allocated object?
- humanrebar 4y agoYes. You can provide a stubbed out deleter or a stack based allocator. But you're then responsible for making sure the unique_ptr doesn't outlive that stack memory. Though that's true for any reference to stack memory.
- rightbyte 4y agounqie_ptr have overhead. It need to run its dtor etc. https://www.youtube.com/watch?v=rHIkrotSwcc https://www.youtube.com/watch?v=rHIkrotSwcc At 18 min.
- adev_ 4y ago> unqie_ptr have overhead. It need to run its dtor etc Technically it is correct, it causes an extremly light overhead due to the inability of the compiler to optimise a part of it. In practice, even in HPC, I never notice it to have an impact ever. And as an advise for any new C++ programmers: Please JUST use unique_ptr, everywhere, all the time... Trying to manage the lifetime manually with new/delete in modern C++ is not worth the cost in 99.99% of the case. If the impact of unique_ptr is noticeable in your program, you are very likely in a realm where you should not even doing memory allocation anyway.
- deleted 4y ago[deleted]