«

James Kuyper <> writes:
[...]
> A compiler that warns whenever a loop condition can never be false would
> annoy those people who rely upon the while(1) idiom.

Yes, such compilers exist, and yes, they're annoying.

--
Keith Thompson (The_Other_Keith) kst- <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) writes:
> compare
>
> int fc(int len, struct foo *fob, struct bar *bab)
> {
> ...
>
> for (j = 0; j < len; j++)
> {
> fob[j].a = bab[j].x;
> fob[j].b = bab[j].y + 1;
> fob[j].c = bab[j].d;
> }
>
> ...
> }
>
> versus
>
> int fd(int len, struct foo *fob, struct bar *bab)
> {
> ...
>
> for (j = 0; j < len; j++)
> {
> fop = &fob[j];
> bap = &bab[j];
> fop->a = bap->x;
> fop->b = bap->y + 1;
> fop->c = bap->d;
> }
>
> ...
> }
>
> The first one looks like Pascal or Fortran. The second one looks more
> like C.

An absurd assertion.

> It says 'i don't need the array base and index, just give me
> the pointer'.

Since when has C been about ditching indices and arrays? Not in any version
of the language I've ever used. Then again, my use only dates back to 1989.

Phil
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

James Kuyper <> writes:
> On 10/31/2011 03:38 PM, Ben Pfaff wrote:
> > Kaz Kylheku <> writes:
> >
> >> On 2011-10-31, Joe keane <> wrote:
> >>> Anyway readability is key; to me code like
> >>>
> >>> ct = len;
> >>> fop = fob;
> >>> while (--ct >= 0)
> >>> {
> >>> ...(fop)
> >>> fop++;
> >>> }
> >>>
> >>> is so idiomatic that it's easiest.
> >>
> >> As pointed out upthread, it's an infinite loop should ct ever happen
> >> to be unsigned. Learning disability?
> >
> > It seems likely to me that the compiler would warn that the loop
> > condition cannot ever be true.
>
> "true" => "false".
>
> A compiler that warns whenever a loop condition can never be false would
> annoy those people who rely upon the while(1) idiom.

I see a clear subset relationship separating constant expressions and
expressions that always have the same value. The compiler _must_ be
able to distinguish the two, so it seems a shame if it's unable to
make use of that distinction in situations like these.

Phil
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

On Mon, 2011-10-31, Joe keane wrote:
> In article <>,
> Kaz Kylheku <> wrote:
>>Firstly, you're neglecting to take advantage of parameters being
>>local variables.
>
> I don't like that "feature" of C.
>
> It's harder to debug, it's harder to maintain.

I found your example upthread hard to understand /because/ it didn't
take advantage -- too many (non-const) variables with similar-looking
names.

If you don't intend to modify your parameters, at least make them const.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On 2011-10-31, Phil Carmody <> 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.

> 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.

On 10/31/2011 08:11 PM, Ike Naar wrote:
> On 2011-10-31, Phil Carmody <> 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

On 2011-11-01, James Kuyper <> wrote:
> On 10/31/2011 08:11 PM, Ike Naar wrote:
>> On 2011-10-31, Phil Carmody <> wrote:
>> 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;

*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.

I.e. it's an iterative rewrite of the tail recursion:

void zero_array(int *point, int count)
{
if (count > 0) {
*point = 0;
zero_array(point + 1, count - 1);
}
}

This local modification of arguments lets us write certain cases
of obvious recursion iteratively. Just assign the different values to the
parameters and loop.

On 2011-11-01, James Kuyper <> wrote:
> On 10/31/2011 08:11 PM, Ike Naar wrote:
>> On 2011-10-31, Phil Carmody <> 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.

This is not an example where one needs a local variable to maintain
an unmodified copy of the original. And actually the meanings of
count and point *do* change, initially they describe the entire
set of points, and later on they describe the set of points
yet-to-be-processed. In this simple example the difference is
futile, because there is no reason to keep the entire set for
later reference. Looking at a slightly more complicated example
that *does* need local variables:

void froboz_array(int *point, int count)
{
int *all_point = point;
int all_count = count;
while (count-- > 0)
fro(*point++);

point = all_point;
count = all_count;
while (count-- > 0)
boz(*point++);
}

some might prefer a variant that is almost identical,
but has the advantage that it does not modify the parameters:

void froboz_array(int *all_point, int all_count)
{
int *point = all_point;
int count = all_count;
while (count-- > 0)
fro(*point++);

point = all_point;
count = all_count;
while (count-- > 0)
boz(*point++);
}

In the simpler example that you showed (only one sweep
across the point array), one can make a tradeoff between two
desirable objectives:
a) keeping the parameters constant
b) minimizing the number of local variables

I think a) vs. b) is a honest tradeoff, and not a dumb vs. smart question.

>>> 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.

Phil was talking to Joe; I am not Joe.

On 10/31/2011 10:51 PM, Kaz Kylheku wrote:
> On 2011-11-01, James Kuyper <> wrote:
....
>> *point = 0;
>
> *point++ = 0;

Aaagh! My dogs urgently needed walking, so I didn't spend enough time
proofreading.
--
James Kuyper

On 11/01/2011 05:51 AM, Ike Naar wrote:
> On 2011-11-01, James Kuyper <> wrote:
>> On 10/31/2011 08:11 PM, Ike Naar wrote:
....
>> 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;

Correction:
*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.
>
> This is not an example where one needs a local variable to maintain
> an unmodified copy of the original.

Well, true - that was precisely my point. As a result:

> In the simpler example that you showed (only one sweep
> across the point array), one can make a tradeoff between two
> desirable objectives:
> a) keeping the parameters constant
> b) minimizing the number of local variables
>
> I think a) vs. b) is a honest tradeoff, and not a dumb vs. smart question.

I'm in perfect agreement with that.

....
>>> 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.
>
> Phil was talking to Joe; I am not Joe.

Sorry - I sometimes loose track of who's saying what, paying attention
only to the points that they are arguing. Your points seemed similar to
Joe's. Replace "your" with "Joe's" in the preceding paragraph.
--
James Kuyper