Safer Dynamic Memory Allocation

Your essay covers some interesting points, but I notice it skirts the issue of managing dynamic objects. There are times when you have no choice about this. For example, I deal a lot with shareable libraries that offer their services through opaque objects. Since different versions of the libraries might have entirely different sizes and internal layouts of these objects, it is not practicable to let the caller allocate them on the stack; they have to go on the heap.

And then you have the well-known complications of checking for errors on such allocations, and ensuring that everything is correctly cleaned up on both success and failure code paths. All too often I see a rat’s nest of `goto`s to deal with this, when really the simplest solution is to avoid `goto`s altogether.

More explanation (with examples) here: https://github.com/ldo/a_structured_discipline_of_programming