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 ...

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).

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.

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.