Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > the loop control

Reply
Thread Tools

the loop control

 
 
Keith Thompson
Guest
Posts: n/a
 
      10-31-2011
James Kuyper <(E-Mail Removed)> 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) 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"
 
Reply With Quote
 
 
 
 
Phil Carmody
Guest
Posts: n/a
 
      10-31-2011
(E-Mail Removed) (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
 
Reply With Quote
 
 
 
 
Phil Carmody
Guest
Posts: n/a
 
      10-31-2011
James Kuyper <(E-Mail Removed)> writes:
> On 10/31/2011 03:38 PM, Ben Pfaff wrote:
> > Kaz Kylheku <(E-Mail Removed)> writes:
> >
> >> On 2011-10-31, Joe keane <(E-Mail Removed)> 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
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      10-31-2011
On Mon, 2011-10-31, Joe keane wrote:
> In article <(E-Mail Removed)>,
> Kaz Kylheku <(E-Mail Removed)> 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 .
 
Reply With Quote
 
Ike Naar
Guest
Posts: n/a
 
      11-01-2011
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.

> 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.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-01-2011
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
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      11-01-2011
On 2011-11-01, 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:
>> 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.
 
Reply With Quote
 
Ike Naar
Guest
Posts: n/a
 
      11-01-2011
On 2011-11-01, 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.


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.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-01-2011
On 10/31/2011 10:51 PM, Kaz Kylheku wrote:
> On 2011-11-01, James Kuyper <(E-Mail Removed)> wrote:

....
>> *point = 0;

>
> *point++ = 0;


Aaagh! My dogs urgently needed walking, so I didn't spend enough time
proofreading.
--
James Kuyper
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-01-2011
On 11/01/2011 05:51 AM, Ike Naar wrote:
> On 2011-11-01, James Kuyper <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Triple nested loop python (While loop insde of for loop inside ofwhile loop) Isaac Won Python 9 03-04-2013 10:08 AM
Getting a loop to activate a loop above it Byte Python 4 03-24-2006 03:04 AM
Condition outside loop or separate loop for different condition? - Java 12 06-15-2005 08:50 AM
while loop in a while loop Steven Java 5 03-30-2005 09:19 PM
Loop the loop... =?Utf-8?B?VGltOjouLg==?= ASP .Net 2 02-16-2005 12:21 PM



Advertisments