Goto out of a block: do destructors get 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 ?

The C++ Standard says:

> On exit from a scope (however > accomplished), destructors (12.4) are > called for all constructed objects > with automatic storage duration > (3.7.2) (named objects or temporaries) > that are declared in that scope, in > the reverse order of their > declaration.

So the answer is "yes".

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 use goto, 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 a goto goes to a single location, it's very clear what destructors must be called before the control-flow transfer. But with a computed goto, 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 computed gotos in concert with objects with non-trivial destructors.

Although the destructor is meant to be called, note that gcc has a bug:

If your code is of the following form, where you return the class and also do a jump that should cause it to be destructed, the destructor is skipped.

CSomeClass foo()
{
    label:
    CSomeClass bar;

    // Some code here...

    if (someCondition)
       goto label; // if this jump is taken, bar is not destructed in gcc

    return bar;
}