size_t problems

[Flash Gordon]

Malcolm McLean wrote, On 07/09/07 21:58:

Ten thousand pounds, or twenty thousand UD dollars, is by business
standards quite a small amount of money.

We are a small company. In any case, why should we bare the costs for
*your* ideas and wants?

If you are at all typical your
costs are not in the hardware,

This year HW is a significant cost, so significant that we are having to
borrow the money to do it.

BTW, I was understating the real costs, those would be much higher since
we have already bought the replacement HW and would have to upgrade it.

which in any case doubles in speed and
capacity every eighteen months or so, but in the software.

The existing HW is failing NOW. If we wait 18 months, or even 6 months,
we could have lost out entire customer base for half of our products.

 

[CBFalconer]

.... snip ...

so your replacement reads:

j = 7;
do {
if ( (bitmap >> j) & 1 )
{
has_field[k] = TRUE;
}
else
{
has_field[k] = FALSE;
}
++k;
} while (j--);

To me, the first option is more readable by far. for(...) loops
are excellent for looping over an index, doing the same with
while(..) and do while(...) loops, gives me headache.

Note the simplicity of:

j = 7;
do {
has_field[k++] = (bitmap >> j) & 1;
} while (j--);

which obviously executes for j = 7, 6, ... 0 and stops.

 

[Tor Rustad]

Tor Rustad wrote:
... snip ...

so your replacement reads:

j = 7;
do {
if ( (bitmap >> j) & 1 )
{
has_field[k] = TRUE;
}
else
{
has_field[k] = FALSE;
}
++k;
} while (j--);

To me, the first option is more readable by far. for(...) loops
are excellent for looping over an index, doing the same with
while(..) and do while(...) loops, gives me headache.

Note the simplicity of:

j = 7;
do {
has_field[k++] = (bitmap >> j) & 1;
} while (j--);

which obviously executes for j = 7, 6, ... 0 and stops.

Sorry, I don't find your *style* an easy read, we clearly differ in
opinions on this, you might get away with a one-liner, but my basic
point still stands. Even in the above compressed version, I find this
more readable:

for(j=7; j>=0; j--)
{
has_field[k++] = (bitmap >> j) & 1;
}

When looping over a known range (j = 7, 6, ... 0), the natural choice is
to use for loops. When not knowing in advance the number of iterations,
that's when while() and do while() loops comes into play.


"To this day, many C programmers believe that 'strong typing' just means
pounding extra hard on the keyboard."
-Peter van der Linden, "Expert C Programming"


So what is "wrong" with:

has_field[k++] = (bitmap >> j) & 1;

?

'has_field' has a boolean type, which was typedef'ed elsewhere together
with the TRUE and FALSE macros. So not only have you hard-coded the
values of TRUE and FALSE, but also assume LHS and RHS will have the same
type.

 

[CBFalconer]

Tor Rustad wrote:

... snip ...

so your replacement reads:

j = 7;
do {
if ( (bitmap >> j) & 1 )
{
has_field[k] = TRUE;
}
else
{
has_field[k] = FALSE;
}
++k;
} while (j--);

To me, the first option is more readable by far. for(...) loops
are excellent for looping over an index, doing the same with
while(..) and do while(...) loops, gives me headache.

Note the simplicity of:

j = 7;
do {
has_field[k++] = (bitmap >> j) & 1;
} while (j--);

which obviously executes for j = 7, 6, ... 0 and stops.

Sorry, I don't find your *style* an easy read, we clearly differ
in opinions on this, you might get away with a one-liner, but my
basic point still stands. Even in the above compressed version,
I find this more readable:

for(j=7; j>=0; j--)
{
has_field[k++] = (bitmap >> j) & 1;
}

That won't work. The original of this was to implement the loop
with unsigned loop variables, so the >= 0 test is always true.

 

[Tor Rustad]

Tor Rustad wrote:
[...]

for(j=7; j>=0; j--)
{
has_field[k++] = (bitmap >> j) & 1;
}

That won't work. The original of this was to implement the loop
with unsigned loop variables, so the >= 0 test is always true.

I fixed *my* bug a long time ago, by using

int j;

 

[Kelsey Bjarnason]

[snips]

Ten thousand pounds, or twenty thousand UD dollars, is by business standards
quite a small amount of money.

Yet since the cost would be for *no* purpose other than to make *you*
happy, you should be the one to pay it. For every company, every person,
every organization which has to increase their hardware costs just to meet
your weird little preferences.

Going to fork over the dough? No, thought not.

Increased costs where there is a justification for them is generally
acceptable. Making Malcolm happy is not a justification for such costs.

 

[David Thompson]

"const" in a parameter declaration doesn't do anything useful for the
caller, since (as I'm sure you know) a function can't modify an
argument anyway. It does prevent the function from (directly)
modifying its own parameter (a local object), but that's of no concern
to the caller.

It would make more sense to be able to specify "const" in the
*definition* of a function but not in the *declaration*. And gcc
seems to allow this:

int foo(int x);

int foo(const int x)
{
return x;
}

but I'm not sure whether it's actually legal. In any case, it's not a
style that seems to be common.

It is. C99 6.7.5.3p15 not significantly changed from C90 6.5.4.3:
For two function types to be compatible, both shall specify compatible
return types.
Moreover, the parameter type lists, if both are present, shall agree
in the number of
parameters and in use of the ellipsis terminator; corresponding
parameters shall have
compatible types. <snip stuff about oldstyle vs newstyle>
(In the determination of type
compatibility and of a composite type, each parameter declared with
function or array
type is taken as having the adjusted type and each parameter declared
with qualified type
is taken as having the unqualified version of its declared type.)

Thus the definition is compatible with the declaration (and vice
versa), so no constraint is violated, and calls must work. (Assuming
no CV or UB elsewhere, of course.)

OTOH I have encountered a compiler that got this wrong -- IIRC (some
version of) AIX xlc. Plus, it provides IMJ very little benefit.

- formerly david.thompson1 || achar(64) || worldnet.att.net