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 gotos to deal with this, when really the simplest solution is to avoid gotos altogether.
More explanation (with examples) here: https://github.com/ldo/a_structured_discipline_of_programming
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
gotos to deal with this, when really the simplest solution is to avoidgotos altogether.More explanation (with examples) here: https://github.com/ldo/a_structured_discipline_of_programming