Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

the loop control

 
 
Seebs
Guest
Posts: n/a
 
      10-31-2011
On 2011-10-31, jgharston <(E-Mail Removed)> wrote:
> James Kuyper wrote:
>> 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 not a feature of C, it's a feature of subroutines.
> I can't think of any programming language where the
> passed parameters are not local to the subroutine.


At least some Fortrans. Everything was passed by reference, and yes,
this meant that if you called a routine that modified a parameter with
a constant, the constant might get changed.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
 
Reply With Quote
 
 
 
 
Sjouke Burry
Guest
Posts: n/a
 
      10-31-2011
jgharston <(E-Mail Removed)> wrote in news:c173def7-db03-4bf0-adf5-
(E-Mail Removed):

> James Kuyper wrote:
>> 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 not a feature of C, it's a feature of subroutines.
> I can't think of any programming language where the
> passed parameters are not local to the subroutine.
>
> I'm happy for somebody to enlighten me, though.
>
> JGH
>


Ever heard of FORTRAN?
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      10-31-2011
On 10/31/2011 01:27 PM, jgharston wrote:
> James Kuyper wrote:
>> Kaz Kylheku wrote:
>>> Firstly, you're neglecting to take advantage of parameters being
>>> local variables.

>> I don't like that "feature" of C.


I didn't write that last sentence; it was written by Joe Keane. You need
to fix up your quoting system.

> It's not a feature of C, it's a feature of subroutines.


It's a feature of C subroutines; there are other languages that do not
share that feature.

> I can't think of any programming language where the
> passed parameters are not local to the subroutine.


See <http://en.wikipedia.org/wiki/Evaluation_strategy>; C's
call-by-reference approach is far from being universal. With most of the
other strategies, it would be a bad idea to treat a function parameter
as a local variable.
 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      10-31-2011
On 2011-10-31, Joe keane <(E-Mail Removed)> 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.


This feature is found in other languages.

(defun lisp-function (arg)
(incf arg))

> It's harder to debug, it's harder to maintain.


This sort of statement is impossible to justify without a lot of
qualifications. Undoubtedly whenever you modify *any* variable, be it
a by-value argument or not, you can create bugs. (Just ask any proponent of
functional languages.)

The trick of destructively manipulating by-value arguemnts keeps
small and simple functions small and simple, where extra variables
might just create clutter.

Everything you add to the function, some maintainer will have to suspect was
done for a significant reason beyond mere style.

>>Do you need fool and foob to retain the values they had on entry into
>>the function?

>
> It helps to retain sanity.


N
> e.g.
>
> int f2(int len, struct foo *fob)
> {
> ...
>
> for (j = 0; j < len; j++)
> {
> fob->a = fq(...);
> fob++;
> }
>
> ...
>
> for (j = 0; j < len; j++)
> {
> fob->b = fr(...);
> fob++;
> }
>
> ...
> }
>
> Oops!


This function suggests to me that it is two functions combined into one.

Or, possibly, that the separate loop bodies can be combined into a single pass.

If there is no need for two passes, then the above code wastes my time
trying to confirming a suspicion that there have to be two passes,
because I respect the intelligence of the prior coder and assume he or
she did things for a good reason.

Thus if the following is a correct rewrite, then it is better:

for (j = 0; j < len; j++)
{
fob->a = fq(...);
fob->b = fr(...);
fob++;
}

 
Reply With Quote
 
Kaz Kylheku
Guest
Posts: n/a
 
      10-31-2011
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?

C programmers who know what they are donig rarely use predecrement like this in
descending loops, because the counter decrements even in the case that the loop
guard fails and the body is not to be executed any more, which means that it
decrements one past zero.
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      10-31-2011
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.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1utchar(a[i&15]);break;}}}
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      10-31-2011
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.
 
Reply With Quote
 
Ben Pfaff
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.


The compiler is smarter than that (I see that it isn't actually
specific to loop conditionals):

blp@blp:~/nicira/openflow(0)$ cat foo.c
int
main(void)
{
unsigned x = 5;
while (--x >= 0) {
;
}
while (1) {
;
}
return 0;
}
blp@blp:~/nicira/openflow(0)$ gcc -Wall -Wextra foo.c
foo.c: In function 'main':
foo.c:5: warning: comparison of unsigned expression >= 0 is always true
blp@blp:~/nicira/openflow(0)$

--
"To get the best out of this book, I strongly recommend that you read it."
--Richard Heathfield
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-31-2011
jgharston <(E-Mail Removed)> writes:
> James Kuyper wrote:
>> 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 not a feature of C, it's a feature of subroutines.
> I can't think of any programming language where the
> passed parameters are not local to the subroutine.
>
> I'm happy for somebody to enlighten me, though.


It's a feature of C.

Another example: in Ada, parameters (unless they're marked "in out" or
"out") are local to the subroutine, but they're constant (read-only).
If you try to assign a value to a parameter, the compiler will complain.

--
Keith Thompson (The_Other_Keith) (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:
> 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.
>
> >Do you need fool and foob to retain the values they had on entry into
> >the function?

>
> It helps to retain sanity.
>
> e.g.
>
> int f2(int len, struct foo *fob)
> {
> ...
>
> for (j = 0; j < len; j++)
> {
> fob->a = fq(...);
> fob++;
> }
>
> ...
>
> for (j = 0; j < len; j++)
> {
> fob->b = fr(...);
> fob++;
> }
>
> ...
> }
>
> Oops!


Needing to use something more than once, where use modifies that
thing, clearly requires you to maintain an unmodified copy of the
original.

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.

Phil
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator
 
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