compilation - C++, variable declaration in 'if' expression

Question

What's going on here?

if(int a = Func1())
{
    // Works.
}

if((int a = Func1()))
{
    // Fails to compile.
}

if((int a = Func1())
    && (int b = Func2()))
)
{
    // Do stuff with a and b.
    // This is what I'd really like to be able to do.
}

Section 6.4.3 in the 2003 standard explains how variables declared in a selection statement condition have scope that extends to the end of the substatements controlled by the condition. But I don't see where it says anything about not being able to put parenthesis around the declaration, nor does it say anything about only one declaration per condition.

This limitation is annoying even in cases where only one declaration in the condition is required. Consider this.

bool a = false, b = true;

if(bool x = a || b)
{

}

If I want to enter the 'if'-body scope with x set to false then the declaration needs parenthesis (since the assignment operator has lower precedence than the logical OR), but since parenthesis can't be used it requires declaration of x outside the body, leaking that declaration to a greater scope than is desired. Obviously this example is trivial but a more realistic case would be one where a and b are functions returning values that need to be tested

So is what I want to do non-conformant to the standard, or is my compiler just busting my balls (VS2008)?

Answer 1

I think you already hinted at the issue. What should the compiler do with this code?

if (!((1 == 0) && (bool a = false))) {
    // what is "a" initialized to?

The "&&" operator is a short-circuit logical AND. That means that if the first part (1==0) turns out to be false, then the second part (bool a = false) should be not be evaluated because it is already known that the final answer will be false. If (bool a = false) isn't evaluated, then what to do with code later on that uses a? Would we just not initialize the variable and leave it undefined? Would we initialize it to the default? What if the data type was a class and doing this had undesirable side effects? What if instead of bool you used a class and it had no default constructor such that the user must provide parameters - what do we do then?

Here's another example:

class Test {
public:
    // note that no default constructor is provided and user MUST
    // provide some value for parameter "p"
    Test(int p);
}

if (!((1 == 0) && (Test a = Test(5)))) {
    // now what do we do?!  what is "a" set to?

Seems like the limitation you have found seems perfectly reasonable - it prevents these kinds of ambiguities from happening.