Parenthesis

[Steve Horne]

On Sat, 23 Dec 2006 10:44:16 +0000 (UTC), Wolven <rma at wolven.net>
wrote:

>== Quote from Steve Horne (stephenwantshornenospam100 at aol.com)'s article
>> Trying to get the best of both worlds risks bringing in a whole bunch
>> of new problems...
>>   if a == b        //  fine
>>   {
>>     ...
>>   }
>>   if a == b return c;  //  errm - well...
>>   if a == b *c++;       //  aaarrrggghhh!!!
>
>Forgive me for my ignorance (I've never programmed in C), but what isn't clear
>about those statements?

I never said they were ambiguous - I chose them to be increasingly
ugly and with increasing potential to confuse (within the limits of
short, simple examples). After all, if the meaning really is ambiguous
you just disambiguate with extra parens/braces/whatever. But we don't
all agree about what is/is not confusing.

Every programming language I have ever used has a way of explicitly
separating the conditional expression from the body statement in an if
statement. In C family languages its a closing paren. In Basic and Ada
it was the 'then' keyword. In Python it is a colon. There are
languages where a line-break is required, and so on.

The reason that every programming language has some way of explicitly
separating the conditional expression from the body statement is that
doing the separation implicitly allows too much room for confusion.


>Likewise, this one says; if a is equal to b, add one to... pointer c?  Although
>I'm not positive of the meaning of the *, everything else seems crystal clear.

Based on that interpretation, the pointer isn't incremented. The
variable c must be a pointer, and the value it points to is
incremented (and its pre-increment value returned, but discarded). The
prefix '*' operator dereferences a pointer in the same way that a
postfix '^' would do in Pascal. So you spotted the meaning I intended.

Now consider that the '++' operator forms an expression with a
side-effect - not a statement. It is only valid as a statement
because, in C, any expression is a valid statement. So why not
interpret it as an empty-bodied conditional with a side-effect in the
condition expression...

  if (a == (b * (c++)))  { /*  null statement  */ }

Of course this is obviously stupid to you and me - why put this
expression in an if statement. But then, the same expression rules
apply to while loops. And it is quite normal to have while loops that
have no body statements, but which exploit side-effects in the
condition expression. The compiler has to choose based on syntax rules
only, not common sense, and the choice it would make in this case is
the stupid one.

So the interpretation that you considered crystal clear (and that I
originally intended) is, when you put a bit more thought in, simply
wrong. The compiler would interpret it differently.

So tell me again how that isn't confusing...

>I'm just trying to understand WHY C(++) programmers find
>statements that seem perfectly clear  to me, confusing.

C-family languages already have much more potential for confusion than
Pascal-family languages. There even used to be obfuscated C contests.
No-one ever ran an obfuscated Pascal contest that I heard of. In fact,
C-family languages are infamous for being far more confusing
(potentially) than Pascal-family languages. And C-family language
programmers have embraced that and accepted it, gaining the advantages
and taking responsibility for managing the disadvantages.

C programmers simply aren't prone to whining about potential confusion
issues unless they are real.

-- 
Remove 'wants' and 'nospam' from e-mail.