Consider the following code:
void foo()
{
{
CSomeClass bar;
// Some code here...
goto label;
// and here...
}
label:
// and here...
}
Will the destructor of bar be called ?
Consider the following code:
void foo()
{
{
CSomeClass bar;
// Some code here...
goto label;
// and here...
}
label:
// and here...
}
Will the destructor of bar be called ?
Yes, they will be called.
Update: (it's okay to do this, gotos is not worse than throwing dummy exceptions or using bools/ifs to get out of things. A simple goto inside a function don't make it spaghetti code.)
1) Yes. 2) Don't do this.
Elaboration: conceptually, this is no different from leaving a loop via a
break
.goto
, however, is strongly, strongly discouraged. It is almost never necessary to usegoto
, and any use should be scrutinized to find out what's going on.Yes, as everyone else says. C++ specifies/mandates this.
But just to add to that, for completeness: if your
goto
uses the computed-goto
extension found in some compilers -- gcc, clang, possibly others but not including MSVC last I knew -- whether or not the object's destructor will be called is pretty hazy. When agoto
goes to a single location, it's very clear what destructors must be called before the control-flow transfer. But with a computedgoto
, different destructors might need to dynamically be called, to give the "expected" semantics. I'm not sure what compilers that implement this extension do, in those cases. My memory from encountering this is that clang warns when a computed-goto
might leave a scope with an object with a non-trival destructor, claiming the destructor won't be called. In some cases that might be fine, in others not. I don't know offhand what other compilers do. Just be aware of the issue if you want to use computedgoto
s in concert with objects with non-trivial destructors.The C++ Standard says:
So the answer is "yes".