the loop control

[Keith Thompson]

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.

 

[Joe keane]

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]

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)

which, in addition to the minor advantage of being one character
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]

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]

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]

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.



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.

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