3 ms·

I’ve been writing high performance C++ for a while now and this is true. We rarely have memory leaks or use-after-free and when we do, they’re pretty mild. It i

I’ve been writing high performance C++ for a while now and this is true. We rarely have memory leaks or use-after-free and when we do, they’re pretty mild. It is one of the easier problems to avoid, especially if you enforce standards on developers to avoid the most common mistakes (eg the new keyword should be avoided if possible unless providing an rvalue to initialize something safer). I can imagine new or bad developers without strong guidance, or under extreme pressure to ship, would have a harder time with it though. Concurrency is a much harder problem and something we deal with more often. I would consider memory management close to not a concern.

zabzonk 5y ago
> Concurrency is a much harder problem and something we deal with more often. I would consider memory management close to not a concern. Absolutely. The longest lasting bug I've ever had was in some multi-threaded code in a trading server (and nothing to do with memory - shared resources getting corrupted). When I tracked it down (after about 6 months!) I repeatedly banged my head on my desk, yelling "You idiot, you idiot, you idiot!" - referring to me. Compared to stuff like this memory leaks are really easy to test for, detect, and fix. Anyone can write a test harness to see if there is a leak.