Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Invisible wrote:
>>> "while (!(*i < *--j)) {}"
> 
>> C has always advocated piling up a bunch of side effects inside 
>> conditionals.
> 
>   OTOH, once you learn to read it, it's not that bad.

Not in moderation. If something in the condition can't easily be expressed 
outside the condition, it's helpful. For example,
   while (EOF != (c = getchar())) { ... }
You can't really put the assignment outside the condition without 
duplicating that code, and it's kind of an accident of the design of the 
libraries that means you can't find out the result from getchar without 
invoking undesirable side-effect.[1] But convolving the comparison and the 
decrement in this case was unnecessary, I think. Doing the decrement in the 
body would say "keep decrementing until the condition is satisfied", which 
doesn't really come across in the way it's written.

>   It's a bit like using "++i" instead of "i = i + 1". The latter might be
> clearer at first, but once you understand what "++i" means, not really.

You definitely have to look at that expression to figure out what it's 
doing. Of course, they could have reversed the letters and made it a little 
clearer, too.


[1] You don't have this problem with iterators, for example, as you can just 
as for "*j" as often as you want without changing "j".  Eiffel and Ada solve 
it by requiring/suggesting that anything that has side effects doesn't 
return a value. So in Eiffel, there's a (void) procedure to read the next 
character into a buffer inside the object, and a function to get whatever 
character was most recently read, so you don't need to do the assignment 
inside the condition to save the character it returned, the way you need to 
in non-OO C.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message