Which operation is more expensive?(a <= b and a != 0)

[Phil Carmody]

It's typical C to use 'int' unless something else is needed.

Sloppiness is typical too.

Possibly without exception, when the standard library provides an
interface for a function that implies operating over an array of
objects, the number of objects is specified as an unsigned type.
The sanest internal behaviour for those functions is to have the
same unsigned type as the index controlling the loop. So there
are plenty of very common examples of at least implicit unsigned
counters.

It's probably an error if the counter comes in negative [or negative if
it were signed if it's unsigned]

can't parse that, sorry

, but maybe running zero times is fine.

beg = 8;
end = 6;
for (j = beg; j < end; j++)
...

Ewwwww, integer overflow. Were you attemting to put forward a case
*for* the use of unsigned integers, as at least you'd know that you'd
wrap.

Phil
--

I'd argue that there is much evidence for the existence of a God.

Pics or it didn't happen.
-- Tom (/. uid 822)

 

[Harald van Dijk]

Ewwwww, integer overflow. Were you attemting to put forward a case
*for* the use of unsigned integers, as at least you'd know that you'd
wrap.

Maybe I'm being daft, but when does this overflow?

 

[James Kuyper]

Maybe I'm being daft, but when does this overflow?

When the j++ expression is executed with j==INT_MAX, which will happen
unless something is done inside the loop to prevent it from happening.
Were you perhaps thinking of beg=6, end=8?

 

[gwowen]

When the j++ expression is executed with j==INT_MAX, which will happen
unless something is done inside the loop to prevent it from happening.
Were you perhaps thinking of beg=6, end=8?

It says "j < end" not "j != end"

 

[James Kuyper]

It says "j < end" not "j != end"

No, my misreading of that code was more complicated than that - but it's
not worth going into. Harald was right, and Phil and I were both wrong -
the code shown does not result in overflow.

The code shown is probably defective; as written either beg and end are
reversed, or the loop was meant to go downward. However, if beg=8 and
end=6 are simplifications for more complicated statements that,
depending upon the values of the other variables, sometimes result in
beg < end, the more complicated statements could be part of a reasonable
program.

 

[Keith Thompson]

[...]
The code shown is probably defective; as written either beg and end are
reversed, or the loop was meant to go downward. However, if beg=8 and
end=6 are simplifications for more complicated statements that,
depending upon the values of the other variables, sometimes result in
beg < end, the more complicated statements could be part of a reasonable
program.

I think the code was intended to demonstrate a loop that executes 0
times, as implied by the preceding "but maybe running zero times is
fine".

 

[Keith Thompson]

Possibly without exception, when the standard library provides an
interface for a function that implies operating over an array of
objects, the number of objects is specified as an unsigned type.

[...]

And that unsigned type is almost always size_t.

The only exception I can find is the "%n" printf format, which expects a
pointer to an int (or you use "%ln" for long, or "%lln" for long long).

 

[Phil Carmody]

No, my misreading of that code was more complicated than that - but it's
not worth going into. Harald was right, and Phil and I were both wrong -
the code shown does not result in overflow.

Me more than you - I started it!


--

I'd argue that there is much evidence for the existence of a God.

Pics or it didn't happen.
-- Tom (/. uid 822)

 

[Barry Schwarz]

I suppose BWK was demonstrating the same lack of experience and
imagination when he wrote Exercise 2.9 in K&R2, implying...

for (b = 0; x; x &= x - 1)
b++;

...was always faster than...

for (b = 0; x != 0; x >>= 1)
if (x & 01)
b++;

These sorts of tricks are still relevant, just considerably
less significant.

Since BWK started the discussion with the caveat "In a two's
complement system ...", he specifically avoided making a general
assertion. Furthermore, he only claimed it was useful for writing a
faster bit counting function, not that it had some property of
universal superiority.

It wouldn't surprise me if the trick had other applications also. It
also wouldn't surprise me if there were other non-obvious tricks which
could be proven to increase efficiency.

But neither of those points has anything to do with my comment that
the author of the original assertion that started this thread was
making global pronouncements without any supporting basis.