tags:

views:

342

answers:

4

What is the "hanging else" problem? (Is that the right name?)

Following a C++ coding standard (forgot which one) I always use brackets (block) with control structures. So I don't normally have this problem (to which "if" does the last(?) else belong), but for understanding possible problems in foreign code it would be nice with a firm understanding of this problem. I remember reading about it in a book about Pascal many years ago, but I can't find that book.

+4  A: 

Which if does the else belong to?

if (a < b)
    if (c < d)
        a = b + d;
    else
        b = a + c;

(Obviously you should ignore the indentation.)

That's the "hanging else problem".

C/C++ gets rid of the ambiguity by having a rule that says you can't have an-if-without-an-else as the if-body of an-if-with-an-else.

RichieHindle
I never understood the problem, to be honest. I am inexperienced in the languages area, but every one that i've used defines the behavior just fine. if instead the problem was if(1) if(some_condition) a = 1; ; else b = 1; then it's an entirely different flow of control in C (compared to the flow you posted), for instance.
San Jacinto
The problem is that the indentation says one thing while the language says another. It's a non-problem in C# because the editor will fix the indentation so that it matches the language's interpretation.
Steven Sudit
@Steven: I'm not a C# programmer and so I might be wrong but I wasn't aware there was one and only one editor. ;)
Troubadour
"C/C++ gets rid of the ambiguity by having a rule that says you can't have an if without an else as the body of an if." Of course you can. `if (a < b) if (c < d) a = b + d;`.
avakar
@Peter: I've rendered that statement infinitely more comprehensible by the insertion of several hyphens. 8-)
RichieHindle
@avakar: Sorry, now fixed.
RichieHindle
I think an easier way to explain the C/C++ rule is the usual one: `else` always binds to the closest matching `if`.
Pavel Minaev
@Troubadour: There are as many editors as you like, but the default one is right in the IDE, and it fixes formatting. Notepad won't, but the various high-end replacement editors will
Steven Sudit
+9  A: 

Ambiguous else.

Some info here: http://theory.stanford.edu/~amitp/yapps/yapps-doc/node3.html

But the classic example is:

if a then
  if b then
     x = 1;
  else 
     y = 1;

vs.

if a then
  if b then
     x = 1;
else 
  y = 1;
Joe
From the parser's point of view, the problem is that you can't resolve the ambiguity from the productions in language's grammar alone. The parser needs extra information, specifically a rule saying how to resolve it. (All the languages I know have a rule that says the else binds with the most recent if.)
Adrian McCarthy
+1  A: 

Looking at this from a langauge design point of view.

The standard BNF Like grammer for if-else

Statement :-   .. STUFF..
          |    IfStatement

IfStatement :- IF_TOKEN '(' BoolExpression ')' Statement IfElseOpt

IfElseOpt :-   /* Empty */
          |    ELSE_TOKEN Statement

Now from a parsers point of view

if (cond1) Statement1
   if (cond2) Statement2
else Statement3

When you get to the ELSE_TOKEN the parser has two options SHIFT or REDUCE. The problem is that which to choose requires another rule that the parser must follow. Most parsers generators default to SHIFT when given this option.

Martin York
Except that C++ is usually not parsed with a shift-reduce (i.e. LR(k)) parser. ;)
avakar
Maybe not. But the __concept__ is the same and I did not want to discuss all the potential parsing schems as it did not really seem relavant.
Martin York
A: 

I don't see the problem for pascal ?

This one is incorrectly indented.

if a then
  if b then
     x = 1;
  else 
     y = 1;

Removing the semi-colon from after x = 1 would make it correctly indented.

This one correctly indented

if a then
  if b then
     x = 1;
else 
  y = 1;
Despatcher