|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |