Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #12264 > unrolled thread

the loop control

Back to article view | Back to comp.lang.c

Contents

  the loop control jgk@panix.com (Joe keane) - 2011-10-29 21:38 +0000
    Re: the loop control Ian Collins <ian-news@hotmail.com> - 2011-10-30 10:48 +1300
    Re: the loop control Kaz Kylheku <kaz@kylheku.com> - 2011-10-29 22:10 +0000
      Re: the loop control jgk@panix.com (Joe keane) - 2011-10-31 15:21 +0000
        Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-10-31 11:35 -0400
          Re: the loop control jgharston <jgh@arcade.demon.co.uk> - 2011-10-31 10:27 -0700
            Re: the loop control Seebs <usenet-nospam@seebs.net> - 2011-10-31 18:36 +0000
            Re: the loop control Robert Wessel <robertwessel2@yahoo.com> - 2011-10-31 13:49 -0500
            Re: the loop control Sjouke Burry <s@b> - 2011-10-31 18:49 +0000
            Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-10-31 15:07 -0400
            Re: the loop control Keith Thompson <kst-u@mib.org> - 2011-10-31 13:56 -0700
        Re: the loop control Seebs <usenet-nospam@seebs.net> - 2011-10-31 17:18 +0000
          Re: the loop control Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-01 04:35 -0700
            Re: the loop control Seebs <usenet-nospam@seebs.net> - 2011-11-01 21:44 +0000
              Re: the loop control Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-02 01:16 -0700
        Re: the loop control Kaz Kylheku <kaz@kylheku.com> - 2011-10-31 19:23 +0000
          Re: the loop control jgk@panix.com (Joe keane) - 2011-11-02 04:47 +0000
        Re: the loop control Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-31 23:07 +0200
          Re: the loop control Ike Naar <ike@sverige.freeshell.org> - 2011-11-01 00:11 +0000
            Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-10-31 22:01 -0400
              Re: the loop control Kaz Kylheku <kaz@kylheku.com> - 2011-11-01 02:51 +0000
                Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-11-01 07:23 -0400
              Re: the loop control Ike Naar <ike@iceland.freeshell.org> - 2011-11-01 09:51 +0000
                Re: the loop control pete <pfiland@mindspring.com> - 2011-11-01 05:34 -0500
                Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-11-01 07:30 -0400
                Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-11-01 07:35 -0400
              Re: the loop control Hans Vlems <hvlems@freenet.de> - 2011-11-11 00:38 -0800
          Re: the loop control jgk@panix.com (Joe keane) - 2011-11-02 03:36 +0000
            Re: the loop control Ian Collins <ian-news@hotmail.com> - 2011-11-02 17:09 +1300
              Re: the loop control Keith Thompson <kst-u@mib.org> - 2011-11-02 03:56 -0700
        Re: the loop control Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-31 21:38 +0000
    Re: the loop control Acid Washed China Blue Jeans <chine.bleu@yahoo.com> - 2011-10-29 19:31 -0700
    Re: the loop control Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-10-29 23:11 -0600
    Re: the loop control "Philip Lantz" <prl@canterey.us> - 2011-10-29 22:47 -0700
      Re: the loop control jgk@panix.com (Joe keane) - 2011-10-31 16:36 +0000
        Re: the loop control Kaz Kylheku <kaz@kylheku.com> - 2011-10-31 19:30 +0000
          Re: the loop control blp@cs.stanford.edu (Ben Pfaff) - 2011-10-31 12:38 -0700
            Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-10-31 15:51 -0400
              Re: the loop control blp@cs.stanford.edu (Ben Pfaff) - 2011-10-31 13:06 -0700
              Re: the loop control Keith Thompson <kst-u@mib.org> - 2011-10-31 14:17 -0700
                Re: the loop control Seebs <usenet-nospam@seebs.net> - 2011-11-01 21:44 +0000
              Re: the loop control Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-31 23:30 +0200
          Re: the loop control jgk@panix.com (Joe keane) - 2011-11-03 21:29 +0000
            Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-11-03 18:00 -0400
            Re: the loop control Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 00:43 +0000
              Re: the loop control jgk@panix.com (Joe keane) - 2011-11-11 02:24 +0000
        Re: the loop control Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-31 23:20 +0200
        Re: the loop control pete <pfiland@mindspring.com> - 2011-10-31 18:01 -0500
          Re: the loop control Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-02 01:20 +0200
    Re: the loop control 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-02 01:25 -0700

Page 1 of 3  [1] 2 3  Next page →

#12264 — the loop control

Which is better?

int fa(int fool, struct foo *foob)
{
    int ct;
    struct foo *foop;

    ...

    ct = fool;
    foop = foob;

    while (--ct >= 0)
    {
	...(foop)
	foop++;
    }

    ...
}

int fb(int fool, struct foo *foob)
{
    struct foo *foop;
    struct foo *fooe;

    ...

    foop = foob;
    fooe = foob + fool;

    while (foop < fooe)
    {
	...(foop)
	foop++;
    }

    ...
}

[toc] | [next] | [standalone]

#12265

On 10/30/11 10:38 AM, Joe keane wrote:
> Which is better?

Start by defining better!

> int fa(int fool, struct foo *foob)
> {
>      int ct;
>      struct foo *foop;
>
>      ...
>
>      ct = fool;
>      foop = foob;
>
>      while (--ct>= 0)
>      {
> 	...(foop)
> 	foop++;
>      }
>
>      ...
> }
>
> int fb(int fool, struct foo *foob)
> {
>      struct foo *foop;
>      struct foo *fooe;
>
>      ...
>
>      foop = foob;
>      fooe = foob + fool;
>
>      while (foop<  fooe)
>      {
> 	...(foop)
> 	foop++;
>      }
>
>      ...
> }


-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#12266

On 2011-10-29, Joe keane <jgk@panix.com> wrote:
> Which is better?

Neither. Firstly, you're neglecting to take advantage of parameters being
local variables. Do you need fool and foob to retain the values
they had on entry into the function?

int fa(int fool, struct foo *foob)
{
  while (fool-- > 0) {
    /* process object referenced by foob */
    foob++;
  }
}

>     while (--ct >= 0)

Getting into the habit of coding a descending loop this way will bite
you if the loop counter is ever an unsigned type. (Hopefully a compiler will
warn you that the comparison is always true because of the range of the type.)

If you're going to introduce an extra integer index variable anyway, consider
array indexing.

  for (ct = 0; ct < fool; ct++) {
     ... foob[i] ...
  }

This way you avoid introducing an extra pointer just to keep your
foob pointer stable.

If this array of struct foo is used frequently in the program,
you might want to encapsulate it better, so you don't have to keep
passing two parameters everywhere just to represent one object.

A null-terminated array is a another possibility. This is like
a null-terminated string, but of course the null element is a pointer.
The argument array passed into main is this way.

int fa(struct foo *foob)
{
  for (; *foob != NULL; foob++) {
     /* process foob */
  }
}

[toc] | [prev] | [next] | [standalone]

#12353

In article <20111029175230.259@kylheku.com>,
Kaz Kylheku  <kaz@kylheku.com> 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!

[toc] | [prev] | [next] | [standalone]

#12354

On 10/31/2011 11:21 AM, Joe keane wrote:
> In article <20111029175230.259@kylheku.com>,
> Kaz Kylheku  <kaz@kylheku.com> 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!

I agree; that's a context where you need to keep the original value of
fob. To get compiler enforcement of the idea that it should not be done,
declare fob to as "struct foo * const fob".

However, I don't see anything wrong with

    int f2(int len, struct foo *fob)
    {
        while(len--)
        {
            fob->a = fq(...);
            fob++;
        }
    }

I don't see that as being any harder to debug, any harder to maintain,
and I don't see it as being necessary to retain my sanity (though some
would undoubtedly argue that it's too late for me to worry about that :-) ).

[toc] | [prev] | [next] | [standalone]

#12388

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

[toc] | [prev] | [next] | [standalone]

#12389

On 2011-10-31, jgharston <jgh@arcade.demon.co.uk> 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 / usenet-nospam@seebs.net
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.

[toc] | [prev] | [next] | [standalone]

#12392

On Mon, 31 Oct 2011 10:27:09 -0700 (PDT), jgharston
<jgh@arcade.demon.co.uk> 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.
>
>I'm happy for somebody to enlighten me, though.


Cobol, Fortran, VB, and Perl, for example, use call-by-reference by
default.  Those also support call-by-value as an option (at least in
more recent incarnations - older versions of Cobol, for example, did
not, but the current standards do).  Conversely, the (more common)
languages that use call-by-value, very often have a way to implement
call-by-reference (in C you can explicitly pass a pointer, of course,
and arrays are always call-by-reference, in C++ you specify a
parameter as a, *ahem*, reference).

[toc] | [prev] | [next] | [standalone]

#12393

jgharston <jgh@arcade.demon.co.uk> wrote in news:c173def7-db03-4bf0-adf5-
25512709fe9c@a12g2000vbz.googlegroups.com:

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

[toc] | [prev] | [next] | [standalone]

#12396

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.

[toc] | [prev] | [next] | [standalone]

#12406

jgharston <jgh@arcade.demon.co.uk> 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) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#12377

On 2011-10-31, Joe keane <jgk@panix.com> wrote:
> In article <20111029175230.259@kylheku.com>,
> Kaz Kylheku  <kaz@kylheku.com> 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.

It doesn't matter.  It's there.  If you write code which acts like it's
not, it sends up big red flags for any future maintainer of your code.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
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.

[toc] | [prev] | [next] | [standalone]

#12441

On Oct 31, 5:18 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2011-10-31, Joe keane <j...@panix.com> wrote:
>
> > In article <20111029175230....@kylheku.com>,
> > Kaz Kylheku  <k...@kylheku.com> 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.
>
> It doesn't matter.  It's there.  If you write code which acts like it's
> not, it sends up big red flags for any future maintainer of your code.

not if I'm the maintainer

[toc] | [prev] | [next] | [standalone]

#12492

On 2011-11-01, Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> On Oct 31, 5:18?pm, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2011-10-31, Joe keane <j...@panix.com> wrote:
>> > In article <20111029175230....@kylheku.com>,
>> > Kaz Kylheku ?<k...@kylheku.com> 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.

>> It doesn't matter. ?It's there. ?If you write code which acts like it's
>> not, it sends up big red flags for any future maintainer of your code.

> not if I'm the maintainer

I have ended up maintaining a lot of code that was written by someone
who did not anticipate the possibility of other people touching the code.
I have, in my own code, gradually learned to write with the intent that
it should not require you to be me to maintain it or have a good sense for
what it's doing and why.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
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.

[toc] | [prev] | [next] | [standalone]

#12512

On Nov 1, 9:44 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2011-11-01, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
>
> > On Oct 31, 5:18?pm, Seebs <usenet-nos...@seebs.net> wrote:
> >> On 2011-10-31, Joe keane <j...@panix.com> wrote:
> >> > In article <20111029175230....@kylheku.com>,
> >> > Kaz Kylheku ?<k...@kylheku.com> 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.
>
> >> It doesn't matter. ?It's there. ?If you write code which acts like it's
> >> not, it sends up big red flags for any future maintainer of your code.
>
> > not if I'm the maintainer
>
> I have ended up maintaining a lot of code that was written by someone
> who did not anticipate the possibility of other people touching the code.
> I have, in my own code, gradually learned to write with the intent that
> it should not require you to be me to maintain it or have a good sense for
> what it's doing and why.

oh I don't write obfuscated code (not intentionally anyway) but I
expect coding style to vary and don't get all bent out of shape over
minor style issues. And I think this is one of them. We don't pay a
penny for each variable usd so i don't think the occaisional,
technically, redundant one is automatically a "red flag" or a "code
smell".

[toc] | [prev] | [next] | [standalone]

#12397

On 2011-10-31, Joe keane <jgk@panix.com> wrote:
> In article <20111029175230.259@kylheku.com>,
> Kaz Kylheku  <kaz@kylheku.com> 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++;
  }

[toc] | [prev] | [next] | [standalone]

#12510

Do you like the follwing example better?

    int f3(int len, struct foo *fob)
    {
	...

    #ifdef DEBUG
	printf("f3 before\n");
	printf("[ ");
	ct = len;
	fop = fob;
	while (--ct >= 0)
	{
	    printf("<%d,%d> ", fop->e, fop->f);
	    fop++;
	}
	printf("]\n");
    #endif

	ct = len;
	fop = fob;
	while (--ct >= 0)
	{
	    fop->alg |= FOO_ALG_ZYX;
	    gromlyana(fop);
	    fop->erg &= ~FOO_ERG_BAZ;
	    fop++;
	}

    #ifdef DEBUG
	printf("f3 after\n");
	printf("[ ");
	ct = len;
	fop = fob;
	while (--ct >= 0)
	{
	    printf("<%d,%d> ", fop->e, fop->f);
	    fop++;
	}
	printf("]\n");
    #endif

	...
    }

[toc] | [prev] | [next] | [standalone]

#12407

jgk@panix.com (Joe keane) writes:
> In article <20111029175230.259@kylheku.com>,
> Kaz Kylheku  <kaz@kylheku.com> 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

[toc] | [prev] | [next] | [standalone]

#12418

On 2011-10-31, Phil Carmody <thefatphil_demunged@yahoo.co.uk> 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.

[toc] | [prev] | [next] | [standalone]

#12422

On 10/31/2011 08:11 PM, Ike Naar wrote:
> On 2011-10-31, Phil Carmody <thefatphil_demunged@yahoo.co.uk> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web