You are either doing a very bad job of arguing your point or you are exposing yourself as exactly the kind of programmer that Dijkstra was trying to reform in his paper.
The entire point of his paper was that structured language provides a better alternative than using a goto
, with the added observation that rigid thinking and flimsy excuses make for bad programmers.
• structured programming == don't use goto when a better alternative exists
• bad programmers == inflexible thinking and weak excuses
Exceptions are not gotos. They are a clean way to deal with exceptional
== abnormal program failure. They are not appropriate as a replacement for gotos, but their use case overlaps.
(And, believe it or not yourself, exceptions are not so heavy that their use is invalidated. Functions are heavier than gotos. Does your argument extend to say that we should be avoiding functions and other ‘more expensive’, non-machine instruction branch and control constructs as well? Because your final statement certainly seems to say exactly that!)
“I'm saying 'use whatever performs better...”
Wrong. Code-correctness is more important than performance.
And, oddly enough, compilers these days are pretty darn good at making very
performant code out of correct
What correct code gets you is a lot of very critical bonuses:
• lower maintenance cost
• greater readability and comprehension
• fewer errors introduced at all stages of development
• better compiler optimizations for language-appropriate design patterns
• greater usability and interoperability with surrounding code
• increased encapsulation
• increased ability to reason about the code
• less fragile code
It especially kills me when people start spouting premature optimization crap. So goto is a one- or two-instruction opcode. Who the hell cares?
Don’t be an assembler.
It’s a waste of time and it's your compiler's job. The whole purpose of high-level language constructs like functions, objects, exceptions, threads, etc is this: make it easy to write powerful, correct code.
The C++ language makes it possible to write powerful, performant, safe
code in just a few lines of what it costs in a language like C (or assembly).
I can easily reason about high-level control structures and complex data in a way that I cannot in C without interleaving and obfuscating the intent of my code with a constant
stream of error and safety checks -- safety that is built-in to high-level C++ constructs.
Why on earth would I want to use a goto and throw all that away?
Stop hating poor little goto
None of us here hate goto. I've personally argued for its continued existence and occasional utility. (Though, not to anyone of any real importance, AFAIK.)
OP’s code is an example of bad
code and an improper use of goto in C++, and a common but still controversial use in C. Anyone sitting in on a code review would probably reject the code outright and tell the programmer to find a better way to manage his resources than with a goto. If a goto did get through code review, it had better have a pretty good justification. (They do exist!)
Your first example is a pathetic non-response to the question already answered. In the post immediately above yours. But here you go anyway:
auto ptr1 = make_shared...; if (!ptr1) return;
auto ptr2 = make_shared...; if (!ptr2) return;
//end of function
auto ptr1 = make_shared...;
auto ptr2 = make_shared...;
if (ptr1 and ptr2 ...)
Wow, so pretty! So easy. So short and readable. So friggin' unbreakable by an intern's fingers three years from now.
“Also please, try to rewrite this [totally opaque code] without gotos and without adding a dozen more variables or functions:”
Sure. Tell me what the hell it does and I'll gladly tell you how to do it. Until then, it doesn't get into the code base.
Welcome to real-life code review.