"if" block without curly braces makes subsequent "else if" nested

Question

AFAIK, if an "if" block is not provided the curly braces then only 1 statement is considered inside it. e.g.

if(..)
  statement_1;
  statement_2;

Irrespective of tabs, only statement_1 is considered inside the if block.

Following code doesn't get along with that:

int main ()
{
  if(false)  // outer - if
    if(false)  // nested - if
      cout << "false false\n";
  else if(true)
    cout << "true\n";
}

Above code doesn't print anything. It should have printed "true".
It appears as of the else if is automatically nested inside the outer if block. g++ -Wall issues warning, but that is not the question here. Once you put the curly braces, everything goes fine as expected.

Why such different behavior ?
[GCC demo: without braces and with braces].

@tbert [why not](http://stackoverflow.com/questions/1642028/what-is-the-name-of-this-operator)? — iammilind, Jul 31 '12 at 10:45
i dont see why this is an issue, for my time in C++ i've never thought this weird. The nested 'if' and it's next lines all the way to 'else if' and the line after it are part of the same _statement_ which is what is important, line counts do not come into this, just like indenting, which you yourself pointed out, does not either. — osirisgothra, Mar 19 '14 at 13:56

score 61 · Accepted Answer · answered Jul 31 '12 at 06:51

61

The behaviour isn’t actually different, it’s entirely consistent: the whole inner if block – including else if – is considered as one block.

This is a classical ambiguity in parsing, known as the “dangling-else problem”: there are two valid ways of parsing this when the grammar is written down in the normal BNF:

Either the trailing else is part of the outer block, or of the inner block.

Most languages resolve the ambiguity by (arbitrarily) deciding that blocks are matched greedily by the parser – i.e. the else [if] is assigned to the closest if.

answered Jul 31 '12 at 06:51

Konrad Rudolph

530,221
131
937
1,214

1

The link and the last "greedy" line says it all. – iammilind Jul 31 '12 at 06:56
3

That's the fastest +10 I've seen in a while! – Mysticial Jul 31 '12 at 06:58
"Most languages"? Do you know a language which does in another way (well, excepted mandating brackets or ending syntax which are ways to avoid the dandling else, not to solve the ambiguity)? Doing otherwise means that you'll have to check how many else are pending (in if if if else else for instance would be matched with the second if, while in if if if else it would be matched with the first). – AProgrammer Jul 31 '12 at 07:53
3

@AProgrammer I don’t know of any other language, I just wanted to cover my ass. I’m sure there are at least *some* experimental languages which do it differently just because. – Konrad Rudolph Jul 31 '12 at 08:26
python uses indenting to solve the problem (is that an "ending syntax"?:) – Karoly Horvath Jul 31 '12 at 08:27
@Karoly In a way it is, since the parser treads indentation (more specifically, the special tokens INDENT and DEDENT) as explicit block delimiters. – Konrad Rudolph Jul 31 '12 at 08:36

score 6 · Answer 2 · edited Jul 31 '12 at 07:41

Because the else is actually being grouped with the inner if, not the outer one. It's actually being parsed as

int main ()
{
  if(false)  // outer - if (never gets executed)
  { 
    if(false)  // nested - if
    {
        cout << "false false\n";
    } else if(true) {
        cout << "true\n";
    }
  }
}

You can solve the problem by explicitly putting the braces where you want them.

score 2 · Answer 3 · answered Jul 31 '12 at 06:51

2

It shouldn't print anything. It is the equivalent to this, since the second if/else if is one block that belongs to the first if:

  if(false) {
    if(false)  // nested - if
      cout << "false false\n";
    else if(true)
      cout << "true\n";
  }

answered Jul 31 '12 at 06:51

Michael Chinen

17,737
5
33
45

Correct, now the question is .. why – iammilind Jul 31 '12 at 06:52
@iammilind why "why"? `if (...) else` is one statement. That's all. The outer `if` is followed by a statement which only ends at the `if` inside the `else`. It is the same as with regexes - matching `a/b/c` with `(.*)/(.*)`, should group 1 be `a` and group 2 be `b/c` or should group 1 be `a/b` and group 2 be `c`? It is the latter, because regexes are "greedy", and so is the C parser. – glglgl Jul 31 '12 at 06:58
1

@glglgl FYI I inserted the "since..." only after iammilind's comment. At first I just said it was equivalent because I thought it was apparent, but as you can see from the votes, it needed to be clarified more :) – Michael Chinen Jul 31 '12 at 07:02

user396672 · Answer 4 · 2012-07-31T09:20:58.270

It is quite natural from the C parser viepoint.

The parser, while parsing if-statement, parses the condition expression first, then parses the first statement after condition, then looks for else keyword and, if the else presents, parses the second (alternative) statement.

However, the first statement is an if-statement too, so the parser calls the "if-parser" recursively (before testing for else keyword!). This recursive call parses the inner if-else statement completely (including else), and moves token position "past the end" of the whole code fragment.

Any attempt to implement alternative behaviour should involve some additional communication between "outer" and "inner" if-parsers: the outer parser should inform the "inner" not to be greedy(i.e. not to eat the else statement). This would add additional complexity to the language syntax.

score 1 · Answer 5 · answered Jul 31 '12 at 06:56

1

else statement always attaches to nearest if. Without branches nested if itself does not form meaningful statement, so parser goes on.

answered Jul 31 '12 at 06:56

Roman Saveljev

2,544
1
21
20

"if" block without curly braces makes subsequent "else if" nested

5 Answers5

Linked

Related