4 ms·
For unique_ptr, in a release build, no: but in a debug build there's overhead, and more to the point, stepping into the deference in gdb/lldb at least in my exp
by berkut 4y ago
For unique_ptr, in a release build, no: but in a debug build there's overhead, and more to the point, stepping into the deference in gdb/lldb at least in my experience requires stepping through the internals, to the point some of the code we use with them is #ifdeffed hackily to use raw ptrs in some cases to avoid this annoyance.
For shared_ptr, the atomic ref counting can cause surprising overhead due to contention in multi-threaded scenarios, even if just accessing the pointer, depending on how the shared_ptr is passed through functions...
- imron 4y agoThere are settings you can place in .gdbinit to avoid stepping in to internals of anything you don’t want to step into, be it std library classes/functions or your own code. Much nicer than hacky ifdefs.
- exDM69 4y ago> There are settings you can place in .gdbinit to avoid stepping in to internals of anything you don’t want to step into, be it std library classes/functions or your own code. This is exactly what I need. For both, C++ and Rust smart pointers. Can you share any more info on how to set this up?
- imron 4y agoOn mobile at the moment so can’t check my .gdbinit, but a quick search turns up this page which seems relevant: https://sourceware.org/gdb/onlinedocs/gdb/Skipping-Over-Functions-and-Files.html https://sourceware.org/gdb/onlinedocs/gdb/Skipping-Over-Func...