What happens when we combine RAII and GOTO?

Question

I'm wondering, for no other purpose than pure curiosity (because no one SHOULD EVER write code like this!) about how the behavior of RAII meshes with the use of goto (lovely idea isn't it).

class Two
{
public:
    ~Two()
    {
        printf("2,");
    }
};

class Ghost
{
public:
    ~Ghost()
    {
        printf(" BOO! ");
    }
};

void foo()
{
    {
        Two t;
        printf("1,");
        goto JUMP;
    }
    Ghost g;
JUMP:
    printf("3");
}

int main()
{
        foo();
}

When running the following code in Visual Studio 2005 I get the following output.

1,2,3 BOO!

However I imagined, guessed, hoped that 'BOO!' wouldn't actually appear as the Ghost should have never been instantiated (IMHO, because I don't know the actual expected behavior of this code).

What's up?

---

I just realized that if I instantiate an explicit constructor for Ghost the code doesn't compile...

class Ghost
{
public:
    Ghost()
    {
        printf(" HAHAHA! ");
    }
    ~Ghost()
    {
        printf(" BOO! ");
    }
};

Ah, the mystery ...

Confessedly

I believe the behavior is correct. Otherwise, how could you refer variable g after JUMP? – Bid

Answer 1

The standard talks about this explicitly - with an example; 6.7/3 "Declaration statement" (emphasis added by me):

Variables with automatic storage duration are initialized each time their declaration-statement is executed. Variables with automatic storage duration declared in the block are destroyed on exit from the block.

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 local variable with automatic storage duration is not in scope to a point where it is in scope is ill-formed unless the variable has POD type and is declared without an initializer.

[Example:

void f()
{
    //...
    goto lx;  //ill-formed: jump into scope of a
    //...

ly:
    X a = 1;
    //...

lx:
    goto ly;  //OK, jump implies destructor
              //call for a, followed by construction
              //again immediately following label ly
}

—end example]

So it seems to me that MSVC's behavior is not standards compliant - Ghost is not a POD type, so the compiler should issue an error when the the goto statement is coded to jump past it.

A couple other compilers I tried (GCC and Digital Mars) issue errors. Comeau issues a warning (but in fairness, my build script for Comeau has it configured for high MSVC compatibility, so it might be following Microsoft's lead intentionally).

Fruitless

Thanks for finding the spot where this is defined in the standard! However I wonder if ill-formed means it should or shouldn't compile... – Confessedly

"Ill-formed" means that the program is not "well-formed." Compilers are required to only accept and "properly execute" programs that are well-formed. That is, if it is "ill-formed," it is in error. – Torso

@Robert: I added a few words about MSVC's behavior here, as I should have done initially. – Fruitless

@greyfade: but compilers typically accept certain ill-formed programs unless you put them into some kind of "strict" mode. For instance the program int main() { 1LL; } is ill-formed, but it might take some effort to persuade your compiler to tell you that. In this case, though, jumping over an initialization could only be described as an MSVC extension if behaviour is (a) defined by MSVC; and (b) potentially useful. – Fleeman

Your fairness confession sounds like comeau is doing something not standard compliant. However, it emits a warning, so it does all the Standard requires from it. – Breakneck

@litb: Comeau is configured to closely emulate MSVC - I haven't tried mucking around with my build script to be more standards compliant to find out if it'll change the warning to an error. Even so, I'd second Robert Gould's question about what the standard requires when compiling an 'ill-formed' program - all that I could find in the standard about what it means to be ill-formed is that an ill-formed program isn't well-formed. I had always thought that an ill-formed program required compiler to emit an error, but I can't actually find the standard saying that. – Fruitless

@Michael it's saying that in 1.4. For a program with a violation of a diagnosable rule (a rule that is not qualified by "no diagnostic required" and not yielding undefined behavior) "a conforming implementation shall issue at least one diagnostic message". An "ill-formed program" (as defined by 1.3.4) does not necessarily require a diagnostic, however. But that is the case only (as far as i can see) when it violates a rule of the one-definition-rule for which no diagnostic is required. So emission of diagnostics is done on a per-rule basis, not on the basis that a program is ill-formed. – Breakneck

Answer 2

Goto isn't radioactive. Leaving by goto is little different from leaving by exception. Entering by goto should be dictated by convenience, not the limits of the language. Not knowing whether the ghost is constructed or not is a good reason not to do that.

Jump in before the constructor. If you want to jump in after some object is already constructed, enclose it in a new scope or otherwise resolve its lifetime yourself.

Tanh

Answer 3

In this scenario, I have found following approach useful.

void foo()
{
    {
        Two t;
        printf("1,");
        goto JUMP;
    }

    {
        Ghost g;
        // operations that use g.
    }

// g is out of scope, so following JUMP is allowed.
JUMP:
    printf("3");
}

Confining the scope of variable g in your foo() function, will make the goto jump legal. Now, we are not jumping from a place where g is not initialized to a place where g is expected to be initialized.

Delicate