Re^3: if/else syntax

Replies are listed 'Best First'.
Re^4: if/else syntax by gwadej (Chaplain) on Jun 26, 2009 at 16:44 UTC
There's actually no ambiguity in the C syntax for your example. The compiler understands it fine. The problem is that the programmer/reader of the code does not always read it the same way. `if(a) if(b) c(); else d();` [download] According to what I recall, the `else` matches with the nearest `if` in this case. Unfortunately, indentation gives humans fits on this. `if(a) if(b) c(); else d();` [download] This does the same thing (`else` goes with `if(b)`). As I said, there's nothing ambiguous about it. G. Wade	[reply] [d/l] [select]
Re^5: if/else syntax by Anonymous Monk on Jun 26, 2009 at 17:01 UTC
thanks, thats exactly what I'm trying to say, if the programmer knows how the compiler interprets the code he can use it in the right way.	[reply]
Re^5: if/else syntax by ikegami (Patriarch) on Jun 26, 2009 at 17:20 UTC
The compiler understands it fine. Not true. How can the compiler understand it fine when C doesn't define it `if(a) if(b) c(); else d();` [download] means `if(a) { if(b) c(); else d(); }` [download] or `if(a) { if(b) c(); } else d();` [download] Both are right. Neither is right. I don't know if that was fixed in recent versions of C. There's actually no ambiguity in the C syntax for your example. That's not true either. You contradict yourself in the next sentence. You write code for both people and for compilers to read. Ambiguity for either is still ambiguity. Anyway, the topic wasn't ambiguity but (the avoidance of) traps. C's if/else definitely has pitfalls.	[reply] [d/l] [select]
Re^6: if/else syntax by massa (Hermit) on Jun 26, 2009 at 17:33 UTC
Sorry, but you are wrong. Since immemorial times and K&R release 1, `if(a) if(b) c(); else d();` [download] is DEFINED as `if(a) { if(b) c(); else d(); }` [download] But, this does not mean there is no ambiguity. It's just plain wrong to assume things without the braces because software changes constantly. So, one day you have `if( a ) if( b ) c(); else d(); else e();` [download] and then you see some reason for the `else d();` to go away, and you stay with `if( a ) if( b ) c(); else e();` [download] That does not do what you intended and you can be looking for this bug in another place kilometers/miles away (in the code) because you left out some initialization done by `e();` etc etc. IOW: You could do that -- because it's really well-defined behaviour for the C language --, but it does not mean you should. []s, HTH, Massa (κς,πμ,πλ)	[reply] [d/l] [select]
Re^6: if/else syntax by gwadej (Chaplain) on Jun 29, 2009 at 13:34 UTC
I'd suggest you check your standard again. It was defined in K&R and in the ANSI/ISO standard. Update: Just to make sure I hadn't misremembered, I dug out the ISO C++ standard (which is all I have handy at the moment.) Section 6.4.1 addresses this issue. In the second form of `if` statement (the one including `else`), if the first substatement is also an `if` statement then that inner `if` statement shall contain an `else` part. There was also no contradiction in my later statement. The is no ambiguity in the standard (or compiler) interpretation. But there is a problem with the way the programmer will read it. This is why Perl made the braces mandatory and Python made the indention mandatory. G. Wade	[reply] [d/l] [select]
Re^4: if/else syntax by Anonymous Monk on Jun 26, 2009 at 16:27 UTC
so why we can't have a if/else syntax without brackets that behaves just like the ternary operator ? `if a { if b { c } else { d } } or if a { if b { c } } else { d }` [download] Does not matter who the compiler will assume, since if it get implemented we would know it before hand	[reply] [d/l]
Re^5: if/else syntax by Transient (Hermit) on Jun 26, 2009 at 17:21 UTC
Perhaps this will add a bit of enlightenment as to the reasoning behind the exclusion: http://www.nntp.perl.org/group/perl.perl6.language/2004/05/msg17372.html `"We think that nowadays we can edge away from some of the less useful C heritage, as long as we stay close enough to our Perl heritage. (Some would say we've already blown it there... :-)"` [download]	[reply] [d/l]


laziness, impatience, and hubris
	PerlMonks