4 ms·

Smart pointers has some overhead though, even unique_ptr. I like to use raii to handle normal pointers. For many programs memory leaks can just be handled by e

Smart pointers has some overhead though, even unique_ptr. I like to use raii to handle normal pointers. For many programs memory leaks can just be handled by exit, too.

Glamhoth 5y ago
unique_ptr has zero overhead
- cjfd 5y ago
  This appears to be incorrect. I have seen a cppcon talk about that. I think it may have been this one: https://www.youtube.com/watch?v=rHIkrotSwcc https://www.youtube.com/watch?v=rHIkrotSwcc . On the other hand, it is a very, very tiny minority of programmers who have to care about an overhead as low as this. Most of us should not waste one microsecond of our thinking time on this.
- JonChesterfield 5y ago
  Kind of true for unique_ptr as a C++ construct. Sadly if the platform ABI is not ignored there is (usually? might be free on some platforms) overhead relative to a void* when passing one between functions. Also there's the usual code size / compile time hazards of templates.
- berkut 5y ago
  Not when stepping through code in gdb/lldb in my experience in debug builds: they very often end up stepping in to the -> operator implementation for functions, which then requires me to step in again to get to the actual function call I wanted.
  - ncmncm 5y ago
    Measuring overhead of debug builds is a rookie mistake.
    - berkut 5y ago
      I'm not talking about code performance, I'm talking about human time of having to step through extra things while using a debugger to work out what's going on.
      - ncmncm 5y ago
        OK. I rely on "fin" a fair bit, at such times.
- ncmncm 5y ago
  unique_ptr has zero overhead except when passing or returning by move. But I don't find myself doing that anywhere performance matters. The overhead is not inherent, but is rather a consequence of C ABI choices inherited into C++ calling conventions. It is, though, real, and not easily fixed. E.g., RISC-V's ABI binding peobably suffers from the same overhead, not for any good reason, but just because the RISC-V crowd couldn't spare the attention to fix it.
cjfd 5y ago
This would seem to be a very micro optimization, though. If you are in a tight loop, sure, but otherwise I would say that smart pointers are a rather low price to pay. And if you are in a tight loop it may be better to try to avoid memory allocations altogether and try to reuse objects instead. In any case the price of smart pointers is orders of magnitude smaller than the price of what passes as 'modern' software development.
- rightbyte 5y ago
  Sure in general, but I would not call it a micro optimization, if you are choosing between shared_ptr and normal ones or unique_ptr.
charcircuit 5y ago
smart pointers is raii for normal pointers

Smart pointers has some overhead though, even unique_ptr. I like to use raii to handle normal pointers. For many programs memory leaks can just be handled by exit, too.

Glamhoth 5y ago

unique_ptr has zero overhead

cjfd 5y ago
This appears to be incorrect. I have seen a cppcon talk about that. I think it may have been this one: https://www.youtube.com/watch?v=rHIkrotSwcc https://www.youtube.com/watch?v=rHIkrotSwcc . On the other hand, it is a very, very tiny minority of programmers who have to care about an overhead as low as this. Most of us should not waste one microsecond of our thinking time on this.
JonChesterfield 5y ago
Kind of true for unique_ptr as a C++ construct. Sadly if the platform ABI is not ignored there is (usually? might be free on some platforms) overhead relative to a void* when passing one between functions. Also there's the usual code size / compile time hazards of templates.
berkut 5y ago
Not when stepping through code in gdb/lldb in my experience in debug builds: they very often end up stepping in to the -> operator implementation for functions, which then requires me to step in again to get to the actual function call I wanted.
- ncmncm 5y ago
  Measuring overhead of debug builds is a rookie mistake.
  - berkut 5y ago
    I'm not talking about code performance, I'm talking about human time of having to step through extra things while using a debugger to work out what's going on.
    - ncmncm 5y ago
      OK. I rely on "fin" a fair bit, at such times.
ncmncm 5y ago
unique_ptr has zero overhead except when passing or returning by move. But I don't find myself doing that anywhere performance matters. The overhead is not inherent, but is rather a consequence of C ABI choices inherited into C++ calling conventions. It is, though, real, and not easily fixed. E.g., RISC-V's ABI binding peobably suffers from the same overhead, not for any good reason, but just because the RISC-V crowd couldn't spare the attention to fix it.

cjfd 5y ago

This would seem to be a very micro optimization, though. If you are in a tight loop, sure, but otherwise I would say that smart pointers are a rather low price to pay. And if you are in a tight loop it may be better to try to avoid memory allocations altogether and try to reuse objects instead. In any case the price of smart pointers is orders of magnitude smaller than the price of what passes as 'modern' software development.

rightbyte 5y ago
Sure in general, but I would not call it a micro optimization, if you are choosing between shared_ptr and normal ones or unique_ptr.

charcircuit 5y ago

smart pointers is raii for normal pointers