Velocity Reviews > the loop control

# the loop control

Keith Thompson
Guest
Posts: n/a

 11-02-2011
Ian Collins <(E-Mail Removed)> writes:
> On 11/ 2/11 04:36 PM, Joe keane wrote:

[...]
>> A year later, Jim is working on a big new project.
>>
>> He changes:
>>
>> #define HAIRY_MACRO(X, Y) \
>> (((X)& 0x8000) == 0 ? BIGMAC1(Y) : BIGMAC2(Y))
>>
>> to:
>>
>> #define HAIRY_MACRO(X, Y) \
>> (((X)& 0x8000) == 0 ? BIGMAC1(Y) : \
>> ((X)& 0x4000) == 0 ? BIGMAC2(Y) : BIGMAC3(Y))

>
> Reason number 248 for not using function-like macros.

Reason number 1 for not using expressions with side effects as
arguments to function-like macros.

I don't suggest that function-like macros are necessarily a good idea,
especially when inline functions are available, but they *can* be used
reasonably safely if you exercise a reasonable amount of care.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Joe keane
Guest
Posts: n/a

 11-03-2011
I use it all the time.

The idiom

while (--ct >= 0)
...

has the nice property that if ct is negative coming in [almost], the
body is not executed, which is probably what you want.

And similar:

for (j = upp; j < low; j++)
...

e.g.

a = 3;
b = 2;

for (j = a; j < b; j++)
...

You'd be rather surprised if this executed four billion times.

If you need unsigned for a loop counter, there must be some reason for
doing so.

James Kuyper
Guest
Posts: n/a

 11-03-2011
On 11/03/2011 05:29 PM, Joe keane wrote:
> I use it all the time.
>
> The idiom
>
> while (--ct >= 0)
> ...
>
> has the nice property that if ct is negative coming in [almost], the
> body is not executed, which is probably what you want.

A property it shares with
while(ct-- > 0)

shorter, also works as intended even if ct is unsigned.

....
> If you need unsigned for a loop counter, there must be some reason for
> doing so.

That is correct.

Kaz Kylheku
Guest
Posts: n/a

 11-04-2011
On 2011-11-03, Joe keane <(E-Mail Removed)> wrote:
> I use it all the time.
>
> The idiom
>
> while (--ct >= 0)
> ...

This is not an idiom; the meaning of this construct is exactly what
the rules for that combination of symbols say it is.

> has the nice property that if ct is negative coming in [almost], the

Almost, yes. What if it is INT_MIN already?

It also has the property that if ct is zero, it is not executed,
but you didn't catch that because it's not obvious, see below.

> body is not executed, which is probably what you want.

This has the stupid property of testing a value that is not the one
which came in. This makes it awkward to think about.

For what values of ct is the loop executed? It is ct - 1 which is tested, not
ct.

while (ct - 1 >= 0)

which is the same thing as

ct >= 1

which is the same as

ct > 0

Aha! Well, doh, why don't you use THAT condition in the fist place???

while (ct-- > 0) {
}

This still has the property of not executing the loop if ct is negative
coming in. It's algebraically equivalent, get it?

Furthermore, maybe you don't want to unconditionally decrement the variable,
whether or not the loop body executes!

If ct comes in as 0 is it okay to make it -1? That's fine if ct has no
next use after the loop.

Variations on the following are generally better:

for (; ct > 0; ct--) {

}

The loop guard controls the loop AND the increment step, which is part
of the loop.

This still has the virtue that the loop is not executed when ct comes
in as zero or negative. Furthermore, it has the virtue that ct is not
touched either if it is zero or negative. (Furthermore, it won't
decrement down from INT_MIN.)

> And similar:
>
> for (j = upp; j < low; j++)
> ...

This is not similar at all.

> If you need unsigned for a loop counter, there must be some reason for
> doing so.

Like maybe it occurs in code written by someone else you're maintaing?

Joe keane
Guest
Posts: n/a

 11-11-2011
I really don't care if you like

while (ct-- > 0)

versus

while (--ct >= 0)

Pick one you like! And know what issues may occur. Nothing is
foolproof here, and it can't be.

Hans Vlems
Guest
Posts: n/a

 11-11-2011
On Nov 1, 3:01*am, James Kuyper <(E-Mail Removed)> wrote:
> On 10/31/2011 08:11 PM, Ike Naar wrote:
>
> > On 2011-10-31, Phil Carmody <(E-Mail Removed)> wrote:
> >> Needing to use something more than once, where use modifies that
> >> thing, clearly requires you to maintain an unmodified copy of the
> >> original.

>
> > If a local variable is needed to maintain an unmodified copy of the original,
> > one might as well leave the original parameter unmodified,
> > and use a local variable as the entity-to-be-modified.
> > This is (arguably) cleaner, because the meaning of the parameter
> > does not change during the process.

>
> That depends entirely upon how you interpret the meaning of the
> parameter. Like any variable, if it's value varies, it's meaning must be
> something that can be said to remain unchanged despite the fact that the
> value has changed.
>
> The meaning of 'count' and 'point' do not change anywhere within the
> following code:
>
> * * * * void zero_array(
> * * * * * * int *point,
> * * * * * * int count
> * * * * ){
> * * * * * * while(count-- > 0)
> * * * * * * * * *point = 0;
> * * * * }
>
> At the start of the function, and at the end of each pass through the
> loop, 'count' contains the number of elements that still need to be
> zeroed, and if that count is non-zero, then 'point' points at the first
> of the elements that still need to be zeroed.
>
> >> Needing to use something once, where use modifies that thing, clearly
> >> does not require you to maintain an unmodified copy of the original.

>
> >> If you are unable to see the difference between these cases, then you
> >> will clearly be hampered when it comes to chosing appropriate coding
> >> techniques. That, however, is your problem, and not the language's
> >> problem.

>
> > If somebody has a different view, it's not necessarily because they
> > are "unable" to see things your way.

>
> He's not addressing your failure to agree with him, but rather your
> claim that the alternative approach leads to confusion. He's saying, in
> essence, that any person who would be confused for that reason still has
> a lot to learn about programming.
> --
> James Kuyper

I happen to know Ike and that last sentence had me ROTFL....