Is it true that goto
jumps across bits of code without calling destructors and things?
e.g.
void f() { int x = 0; goto lol; } int main() { f(); lol: return 0; }
Won't x
be leaked?
In fact, IDL's own documentation advises against it. Actually, it doesn't advise against it; it outright states that using it is bad programming: "The GOTO statement is generally considered to be a poor programming practice that leads to unwieldy programs. Its use should be avoided."
In modern programming, the goto statement is considered a harmful construct and a bad programming practice. The goto statement can be replaced in most of C++ program with the use of break and continue statements.
Explanation. A label is an identifier followed by a colon ( : ) and a statement (until C23). Labels are the only identifiers that have function scope: they can be used (in a goto statement) anywhere in the same function in which they appear.
You can completely avoid using goto , by using exceptions , try/catch , and loops as well as appropriate if/else constructs. However, if you realize that you get extremly out of your way, just to avoid it, it might be an indiaction that it would be better to use it.
Warning: This answer pertains to C++ only; the rules are quite different in C.
Won't
x
be leaked?
No, absolutely not.
It is a myth that goto
is some low-level construct that allows you to override C++'s built-in scoping mechanisms. (If anything, it's longjmp
that may be prone to this.)
Consider the following mechanics that prevent you from doing "bad things" with labels (which includes case
labels).
You can't jump across functions:
void f() { int x = 0; goto lol; } int main() { f(); lol: return 0; } // error: label 'lol' used but not defined
[n3290: 6.1/1]:
[..] The scope of a label is the function in which it appears. [..]
You can't jump across object initialisation:
int main() { goto lol; int x = 0; lol: return 0; } // error: jump to label ‘lol’ // error: from here // error: crosses initialization of ‘int x’
If you jump back across object initialisation, then the object's previous "instance" is destroyed:
struct T { T() { cout << "*T"; } ~T() { cout << "~T"; } }; int main() { int x = 0; lol: T t; if (x++ < 5) goto lol; } // Output: *T~T*T~T*T~T*T~T*T~T*T~T
[n3290: 6.6/2]:
[..] Transfer out of a loop, out of a block, or back past an initialized variable with automatic storage duration involves the destruction of objects with automatic storage duration that are in scope at the point transferred from but not at the point transferred to. [..]
You can't jump into the scope of an object, even if it's not explicitly initialised:
int main() { goto lol; { std::string x; lol: x = ""; } } // error: jump to label ‘lol’ // error: from here // error: crosses initialization of ‘std::string x’
... except for certain kinds of object, which the language can handle regardless because they do not require "complex" construction:
int main() { goto lol; { int x; lol: x = 0; } } // OK
[n3290: 6.7/3]:
It is possible to transfer into a block, but not in a way that bypasses declarations with initialization. A program that jumps from a point where a variable with automatic storage duration is not in scope to a point where it is in scope is ill-formed unless the variable has scalar type, class type with a trivial default constructor and a trivial destructor, a cv-qualified version of one of these types, or an array of one of the preceding types and is declared without an initializer. [..]
Likewise, objects with automatic storage duration are not "leaked" when you goto
out of their scope:
struct T { T() { cout << "*T"; } ~T() { cout << "~T"; } }; int main() { { T t; goto lol; } lol: return 0; } // *T~T
[n3290: 6.6/2]:
On exit from a scope (however accomplished), objects with automatic storage duration (3.7.3) that have been constructed in that scope are destroyed in the reverse order of their construction. [..]
The above mechanisms ensure that goto
doesn't let you break the language.
Of course, this doesn't automatically mean that you "should" use goto
for any given problem, but it does mean that it is not nearly as "evil" as the common myth leads people to believe.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With