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.)

> As long as the open/close functions are paired up

Let me stop you right there. I did not downvote you, but I bet that's why others did. If humans were capable of correctly pairing open/close, new/delete, malloc/free, then we could've called C's memory management "good enough" and stopped there. Decades of experience show that humans are completely incapable of doing this at any scale. Small teams can do it for small projects for a small period of time. Large teams on large projects over long eras just can't.

If the advice for avoiding resource errors includes "all the programmer has to remember is...", then forget it. It's not happening. Thus the appeal of GC languages that do this for the programmer, and newer compiled languages like Rust that handle resource cleanup by default unless you deliberately go out of your way to confuse them.