How do I deal with memory leaks? (2022)

> As early as 1981, I pointed out that by reducing the number of objects that I had to keep track of explicitly from many tens of thousands to a few dozens, I had reduced the intellectual effort needed to get the program right from a Herculean task to something manageable, or even easy.

Fast forward a few decades, and we're still very much on this journey of finding the right abstractions/interfaces/libraries/languages. I feel like there must be a complexity equivalent to Parkinson's law: complexity expands to fill the space left in between abstractions.

> How do I deal with memory leaks? > plug in a garbage collector.

Love it!

I think more people need to see this. This is how the creator of C++ thinks we should be writing code. This is what he thinks code should look like. To split a string by whitespace we should use `while (cin >> s)`. We should have a `typedef` in the middle of functions. Iterations should use `.begin()` and `.end()` everywhere. There might even be a bug with a trailing "+" appearing in the output?

Imagine if this was a new language that the dev community was seeing for the first time. It's hard to imagine it gaining much traction.

Strange to see std::sort(), auto_ptr and RAII on the same page, when that combination was always broken.

> Modified February 26, 2022

So while a much older date is probably appropriate, maybe 20-30 years ago, we can at least mark this (2022) until somebody justifies a particular previous date.

What was the last time when Bjarne Stroustrup pushed any code to production?

In raw C, I like to use the "open"/"close" metaphor and when developing, invoke the routes in parallel. For example:

https://repo.autonoma.ca/repo/mandelbrot/blob/HEAD/main.c

When writing:

    fractal.image = image_open( fractal.width, fractal.height );

    image_close( fractal.image );

For C++, developing a unit test framework based on Catch2 and ASAN that tracks new/delete invocations is rather powerful. You can even set it up to discount false positives from static allocations. When the unit tests exercise the classes, you get memory leak detection for free.

(I don't mind down votes, but at least reply with what you don't like about this approach, and perhaps suggest a newer approach that we can learn from; contribute to the conversation, please.)

Remarkably similar to dykstra on debugging.

Good arguments. But for some reason there are still strange people, who prefer calling malloc/free (or new/delete or something similar) manually. Some of them even invent languages with manual-only memory management (like Zig or Odin).

This is how I do it: Claude, how do I deal with memory leaks?