3 ms·

Junior C++ dev here, but I feel like "use smart pointers, if you have to" is not the sentiment I usually hear. Isn’t it usually “use raw pointers, if you have

Junior C++ dev here, but I feel like "use smart pointers, if you have to" is not the sentiment I usually hear. Isn’t it usually “use raw pointers, if you have to”?

okamiueru 3y ago
Yes. The main problem with the talk is that it's just too general. It gives good advice, but it's only really good advice if you understand what it's trying to say, at which point you don't need the advice. Kinda impossible to cover "what every programmer needs to know" in 5 minutes. So, "use smart points, if you have to", should have been: "if you need to allocate memory dynamically, use smart pointers".
- shrimp_emoji 3y ago
  > if you need to allocate memory dynamically, use smart pointers Oooh. Okay. :p I was like, "As opposed to what, raw pointers?!"
flohofwoe 3y ago
As always the answer is "it depends". Smart pointers kind of 'encourage' that each C++ object lives in its own heap allocation, but this quickly becomes a problem if you deal with tens- or hundreds-of-thousands of small C++ objects that way, each in its own heap allocation, and on top a high number of those objects being frequently created and destroyed (for instance with std::make_unique or std::make_shared). I call this a "Java-style C++ code base". Technically this works and it's reasonably safe, because RAII takes care of memory management, just like GC takes care of memory management in Java. But the problem there is deeper: it's not smart pointers vs raw pointers, but that each small object lives in its own heap allocation. That's the typical scenario where you will see memory management becoming a performance problem (for at least two reasons: (1) heap allocation and especially deallocation isn't free, and (2) lots of cache misses when accessing objects that are spread more or less randomly over the address space). Ideally you'd group many similar objects into long-lived and compact arrays, process the data in those arrays in tight loops, minimize pointer indirections, and minimize allocations (ideally you'd only allocate those arrays once at program start, or when those arrays need to grow). Once you did all those things, memory managament suddenly becomes a non-problem (because you only have a handful of long-lived allocations to care about), and RAII becomes a lot less useful (because the 'objects' in those arrays will most likely just be C-style plain-old-data structs). This is basically the 'antithesis' to OOP. And before you know it you're back to writing C code, like it happened to me ;P TL;DR: there is no silver bullet for automatic memory management if performance matters.
- mr_00ff00 3y ago
  I might be totally missing something here, but wouldn’t using raw pointers include using new/delete, so all those small C++ objects would also live on the heap. Are you saying smart pointers and there overhead make the heap allocations even bigger and that’s the cause of the cache misses?
  - flohofwoe 3y ago
    I guess this got lost in the wall of text :) > But the problem there is deeper: it's not smart pointers vs raw pointers, but that each small object lives in its own heap allocation. Smart-pointers do encourage to create small heap allocations though (because unlike raw pointers they manage ownership).
SleepyMyroslav 3y ago
You might want to watch "GoingNative 2013 C++ Seasoning" video or at least check it's slides [1]. It may sound like it is old but the part about pointers is essential for anyone who wants to write C++. IMHO from gamedev: HN is not going to get it ever. They either have moved to high level languages or do not need performance at all. 1. https://sean-parent.stlab.cc/presentations/2013-09-11-cpp-seasoning/cpp-seasoning.pdf https://sean-parent.stlab.cc/presentations/2013-09-11-cpp-se...

Junior C++ dev here, but I feel like "use smart pointers, if you have to" is not the sentiment I usually hear. Isn’t it usually “use raw pointers, if you have to”?

okamiueru 3y ago

Yes. The main problem with the talk is that it's just too general. It gives good advice, but it's only really good advice if you understand what it's trying to say, at which point you don't need the advice. Kinda impossible to cover "what every programmer needs to know" in 5 minutes. So, "use smart points, if you have to", should have been: "if you need to allocate memory dynamically, use smart pointers".

shrimp_emoji 3y ago
> if you need to allocate memory dynamically, use smart pointers Oooh. Okay. :p I was like, "As opposed to what, raw pointers?!"

flohofwoe 3y ago

As always the answer is "it depends". Smart pointers kind of 'encourage' that each C++ object lives in its own heap allocation, but this quickly becomes a problem if you deal with tens- or hundreds-of-thousands of small C++ objects that way, each in its own heap allocation, and on top a high number of those objects being frequently created and destroyed (for instance with std::make_unique or std::make_shared). I call this a "Java-style C++ code base". Technically this works and it's reasonably safe, because RAII takes care of memory management, just like GC takes care of memory management in Java. But the problem there is deeper: it's not smart pointers vs raw pointers, but that each small object lives in its own heap allocation. That's the typical scenario where you will see memory management becoming a performance problem (for at least two reasons: (1) heap allocation and especially deallocation isn't free, and (2) lots of cache misses when accessing objects that are spread more or less randomly over the address space). Ideally you'd group many similar objects into long-lived and compact arrays, process the data in those arrays in tight loops, minimize pointer indirections, and minimize allocations (ideally you'd only allocate those arrays once at program start, or when those arrays need to grow). Once you did all those things, memory managament suddenly becomes a non-problem (because you only have a handful of long-lived allocations to care about), and RAII becomes a lot less useful (because the 'objects' in those arrays will most likely just be C-style plain-old-data structs). This is basically the 'antithesis' to OOP. And before you know it you're back to writing C code, like it happened to me ;P TL;DR: there is no silver bullet for automatic memory management if performance matters.

mr_00ff00 3y ago
I might be totally missing something here, but wouldn’t using raw pointers include using new/delete, so all those small C++ objects would also live on the heap. Are you saying smart pointers and there overhead make the heap allocations even bigger and that’s the cause of the cache misses?
- flohofwoe 3y ago
  I guess this got lost in the wall of text :) > But the problem there is deeper: it's not smart pointers vs raw pointers, but that each small object lives in its own heap allocation. Smart-pointers do encourage to create small heap allocations though (because unlike raw pointers they manage ownership).

SleepyMyroslav 3y ago

You might want to watch "GoingNative 2013 C++ Seasoning" video or at least check it's slides [1]. It may sound like it is old but the part about pointers is essential for anyone who wants to write C++. IMHO from gamedev: HN is not going to get it ever. They either have moved to high level languages or do not need performance at all. 1. https://sean-parent.stlab.cc/presentations/2013-09-11-cpp-seasoning/cpp-seasoning.pdf https://sean-parent.stlab.cc/presentations/2013-09-11-cpp-se...