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

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

Lexical Variables In C Loops (As Compared To Perl Loops)

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

Contents

  Lexical Variables In C Loops (As Compared To Perl Loops) Robbie Hatley <see.my.sig@for.my.address> - 2015-03-21 00:52 -0700
    Re: Lexical Variables In C Loops (As Compared To Perl Loops) Richard Heathfield <rjh@cpax.org.uk> - 2015-03-21 08:28 +0000
      Re: Lexical Variables In C Loops (As Compared To Perl Loops) Robbie Hatley <see.my.sig@for.my.address> - 2015-03-26 20:57 -0700
    Re: Lexical Variables In C Loops (As Compared To Perl Loops) Keith Thompson <kst-u@mib.org> - 2015-03-21 01:29 -0700
      Re: Lexical Variables In C Loops (As Compared To Perl Loops) Robbie Hatley <see.my.sig@for.my.address> - 2015-03-26 21:01 -0700
    Lexical Variables In C Loops (As Compared To Perl Loops) asetofsymbols@gmail.com - 2015-03-21 01:40 -0700
    Re: Lexical Variables In C Loops (As Compared To Perl Loops) jt@toerring.de (Jens Thoms Toerring) - 2015-03-21 08:43 +0000
      Re: Lexical Variables In C Loops (As Compared To Perl Loops) Robbie Hatley <see.my.sig@for.my.address> - 2015-03-26 20:58 -0700
        Re: Lexical Variables In C Loops (As Compared To Perl Loops) Richard Heathfield <rjh@cpax.org.uk> - 2015-03-27 06:12 +0000
        Re: Lexical Variables In C Loops (As Compared To Perl Loops) Keith Thompson <kst-u@mib.org> - 2015-03-26 23:32 -0700
    Re: Lexical Variables In C Loops (As Compared To Perl Loops) Bartc <bc@freeuk.com> - 2015-03-21 10:54 +0000
      Re: Lexical Variables In C Loops (As Compared To Perl Loops) Keith Thompson <kst-u@mib.org> - 2015-03-21 13:54 -0700
      Re: Lexical Variables In C Loops (As Compared To Perl Loops) Robbie Hatley <see.my.sig@for.my.address> - 2015-03-26 21:24 -0700
        Re: Lexical Variables In C Loops (As Compared To Perl Loops) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-27 20:35 +0000
        Re: Lexical Variables In C Loops (As Compared To Perl Loops) Bartc <bc@freeuk.com> - 2015-03-27 21:24 +0000
          Re: Lexical Variables In C Loops (As Compared To Perl Loops) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-28 00:03 +0000
            Re: Lexical Variables In C Loops (As Compared To Perl Loops) Bartc <bc@freeuk.com> - 2015-03-28 10:00 +0000
          Re: Lexical Variables In C Loops (As Compared To Perl Loops) Stephen Sprunk <stephen@sprunk.org> - 2015-03-28 18:14 -0500
    Re: Lexical Variables In C Loops (As Compared To Perl Loops) Kaz Kylheku <kaz@kylheku.com> - 2015-03-21 14:39 +0000
    Re: Lexical Variables In C Loops (As Compared To Perl Loops) fir <profesor.fir@gmail.com> - 2015-03-21 09:40 -0700
    Re: Lexical Variables In C Loops (As Compared To Perl Loops) James Kuyper <jameskuyper@verizon.net> - 2015-03-21 12:43 -0400
      Re: Lexical Variables In C Loops (As Compared To Perl Loops) Philip Lantz <prl@canterey.us> - 2015-03-21 13:01 -0700
        Re: Lexical Variables In C Loops (As Compared To Perl Loops) James Kuyper <jameskuyper@verizon.net> - 2015-03-22 18:47 -0400
          Re: Lexical Variables In C Loops (As Compared To Perl Loops) Keith Thompson <kst-u@mib.org> - 2015-03-22 16:39 -0700
            Re: Lexical Variables In C Loops (As Compared To Perl Loops) James Kuyper <jameskuyper@verizon.net> - 2015-03-22 20:08 -0400
              Re: Lexical Variables In C Loops (As Compared To Perl Loops) Robbie Hatley <see.my.sig@for.my.address> - 2015-03-26 22:36 -0700
                Re: Lexical Variables In C Loops (As Compared To Perl Loops) Keith Thompson <kst-u@mib.org> - 2015-03-26 23:40 -0700
          Re: Lexical Variables In C Loops (As Compared To Perl Loops) Robbie Hatley <see.my.sig@for.my.address> - 2015-03-26 22:26 -0700
            Re: Lexical Variables In C Loops (As Compared To Perl Loops) Keith Thompson <kst-u@mib.org> - 2015-03-26 23:38 -0700

Page 2 of 2 — ← Prev page 1 [2]

#58590

On 03/21/2015 03:52 AM, Robbie Hatley wrote:
> 
> I was wondering if a variable declared inside a for loop in
> a C program is defined (memory address allocated) just once,
> or if (as in Perl) a fresh (unique) memory address is used
> for each iteration. So I wrote this program to find out:
> 
> /* lexical-var-test.c */
> #include <stdio.h>
> int * array[12];
> int main(int argc, char *argv[])
> {
>     int i = 0;
>     for ( i = 1 ; i <= 10 ; ++i ) {
>        int var = i;
>        array[i] = &var;
>        printf("Addr = %p  Value = %d\n", (void*)array[i], *array[i]);
>     }
>     return 0;
> }
> 
> And the results of running it are:
> 
> Addr = 0x23cb0c  Value = 1
> Addr = 0x23cb0c  Value = 2
> Addr = 0x23cb0c  Value = 3
> Addr = 0x23cb0c  Value = 4
> Addr = 0x23cb0c  Value = 5
> Addr = 0x23cb0c  Value = 6
> Addr = 0x23cb0c  Value = 7
> Addr = 0x23cb0c  Value = 8
> Addr = 0x23cb0c  Value = 9
> Addr = 0x23cb0c  Value = 10
> 
> So while the value changes, the address stays the same, meaning that
> the variable "var" is declared & defined & allocated ONLY ON FIRST
> ITERATION; after that, only the value changes.
> 
> 
> ***** QUESTION: *****
> Is this behavior mandated by the C standard? If so, where? I've been
> looking, but can't find where it discusses this.

"The following identifiers have no linkage: ... a block scope identifier
for an object declared without the storage-class specifier extern."
(6.2.2p6) The declaration of 'var' has block scope and does not use
"extern", so it has no linkage.

"An object exists, has a constant address, and retains
its last-stored value throughout its lifetime." (6.2.4p2)

"An object whose identifier is declared with no linkage and without the
storage-class specifier static has automatic storage duration,"
(6.2.4p5) 'var' has no linkage, and was declared without using "static",
so it has automatic storage duration.

"For such an object that does not have a variable length array type, its
lifetime extends from entry into the block with which it is associated
until execution of that block ends in
any way." (6.2.4p6)

"An iteration statement causes a statement called the loop body to be
executed repeatedly." (6.8.5p4)

"The loop body [of an iteration statement] is also a block ... ".
(6.8.5.3p1)

Thus, the life time of 'var' starts and ends anew each time the loop
body is executed. It is therefore permissible, according to (6.2.4p2)
for the address to be different during different passes through the loop.

However, the memory that used to be allocated for 'var' during the
immediately previous pass through the loop has just been deallocated,
and is guaranteed to have the correct size and the correct alignment in
memory. It is therefore extremely common practice to reuse that piece of
memory. You shouldn't count on it, since it's not mandatory, but you
should also not be surprised by it.
Not that 6.2.4p6 does not apply to objects with variably modified array
type, precisely because those might have a different size during
different passes through the loop.

> For comparison, Perl handles variables VERY differently. Scope, duration,
> definitions, etc.  Check out THIS program:
> 
> use v5.014.004;
> use strict;
> use warnings;
> our @array;
> for (1..10) {
>     my $var = $_;
>     $array[$_] = \$var;
> }
> for (1..10) {
>     say("Addr = $array[$_]  Value = ${$array[$_]}");
> }
> 
> What that prints is THIS:
> 
> Addr = SCALAR(0x6000aa3c8)  Value = 1
> Addr = SCALAR(0x60002c198)  Value = 2
> Addr = SCALAR(0x600070290)  Value = 3
> Addr = SCALAR(0x6000702a8)  Value = 4
> Addr = SCALAR(0x600070368)  Value = 5
> Addr = SCALAR(0x6000703f8)  Value = 6
> Addr = SCALAR(0x600078570)  Value = 7
> Addr = SCALAR(0x600078678)  Value = 8
> Addr = SCALAR(0x600078768)  Value = 9
> Addr = SCALAR(0x600078750)  Value = 10
> 
> Which shows that in Perl, a variable declared in a for loop
> is re-declared & re-defined & re-allocated ON EVERY SINGLE
> ITERATION. Very, very different from C.

As explained above, this is permissible behavior for a C implementation,
so it's not directly a difference between the languages.
-- 
James Kuyper

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

#58599

James Kuyper wrote:
> Robbie Hatley wrote:
> > Which shows that in Perl, a variable declared in a for loop
> > is re-declared & re-defined & re-allocated ON EVERY SINGLE
> > ITERATION. Very, very different from C.
> 
> As explained above, this is permissible behavior for a C implementation,
> so it's not directly a difference between the languages.

Not just permissible but required. What is optional is whether the 
reallocated variable reuses the same address on each iteration.

The difference between C and Perl is that in C the lifetime of the 
variable always ends at the end of each iteration of the loop, whereas 
in Perl the lifetime of the variable may extend beyond the end of the 
iteration of the loop in which it was allocated (and does, in this 
example).

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

#58694

On 03/21/2015 04:01 PM, Philip Lantz wrote:
> James Kuyper wrote:
>> Robbie Hatley wrote:
>>> Which shows that in Perl, a variable declared in a for loop
>>> is re-declared & re-defined & re-allocated ON EVERY SINGLE
>>> ITERATION. Very, very different from C.
>>
>> As explained above, this is permissible behavior for a C implementation,
>> so it's not directly a difference between the languages.
> 
> Not just permissible but required. What is optional is whether the 
> reallocated variable reuses the same address on each iteration.

I suppose I should have made it clearer what I meant - the "permissible"
behavior I was referring to was "reallocating the variable at the same
address ", which is very definitely NOT required. Reallocating the
variable on each iteration is, as you say, mandatory. Declarations and
definitions, on the other hand, are source code constructs, not run-time
behavior, so they only need to be done once, and prior to compilation.

> The difference between C and Perl is that in C the lifetime of the 
> variable always ends at the end of each iteration of the loop, whereas 
> in Perl the lifetime of the variable may extend beyond the end of the 
> iteration of the loop in which it was allocated (and does, in this 
> example).

Can you refer to $var after the end of the loop? If only the memory
persists, rather than access to that memory through the variable name,
then you can't properly say that the variable persists. If you can
access the memory through $var after the loop, which of the ten
different addresses given does it refer to?

I think that he C equivalent of this perl code would not look like
Robbie Hatley's original code, but more like this:

for(int i=1; i<=10; i++)
{
    int *var = malloc(sizeof *var);
    *var = i;
    array[i] = var;
}

-- 
James Kuyper

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

#58698

James Kuyper <jameskuyper@verizon.net> writes:
> On 03/21/2015 04:01 PM, Philip Lantz wrote:
[...]
>> The difference between C and Perl is that in C the lifetime of the 
>> variable always ends at the end of each iteration of the loop, whereas 
>> in Perl the lifetime of the variable may extend beyond the end of the 
>> iteration of the loop in which it was allocated (and does, in this 
>> example).
>
> Can you refer to $var after the end of the loop? If only the memory
> persists, rather than access to that memory through the variable name,
> then you can't properly say that the variable persists. If you can
> access the memory through $var after the loop, which of the ten
> different addresses given does it refer to?

What exactly do you mean by the word "variable"?  The C standard doesn't
define it, so there's no definitive answer.  The way I use it, the word
"variable" is nearly synonymous with "object", except that not all
objects are variables.  In that sense, I'd say that $var can persist
outside the loop, even if it's not visible by that name.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#58702

On 03/22/2015 07:39 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 03/21/2015 04:01 PM, Philip Lantz wrote:
> [...]
>>> The difference between C and Perl is that in C the lifetime of the 
>>> variable always ends at the end of each iteration of the loop, whereas 
>>> in Perl the lifetime of the variable may extend beyond the end of the 
>>> iteration of the loop in which it was allocated (and does, in this 
>>> example).
>>
>> Can you refer to $var after the end of the loop? If only the memory
>> persists, rather than access to that memory through the variable name,
>> then you can't properly say that the variable persists. If you can
>> access the memory through $var after the loop, which of the ten
>> different addresses given does it refer to?
> 
> What exactly do you mean by the word "variable"? ...

A named object. I can cite support for that definition from the C++
standard (3p6), though that definition is far more complex than mine.
However, I'll freely admit that the C standard provides no such
definition. It's just my personal definition, though I did check many
uses of the term as a noun in the C standard, and they all seemed
consistent with that definition (the C standard uses "variable" as an
adjective far more often than as a noun, which makes the search difficult).

> ...  The C standard doesn't
> define it, so there's no definitive answer.  The way I use it, the word
> "variable" is nearly synonymous with "object", except that not all
> objects are variables.  In that sense, I'd say that $var can persist
> outside the loop, even if it's not visible by that name.

As a "named object", it ceases to qualify as a variable when the
connection to it's name is no longer usable.
-- 
James Kuyper

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

#59060

On 3/22/2015 5:08 PM, James Kuyper wrote:

> On 03/22/2015 07:39 PM, Keith Thompson wrote:
> > What exactly do you mean by the word "variable"? ...
>
> A named object....

I tend to agree. Perl also takes that tack. As for un-named
objects (which abound in Perl), Perl calls them "referents".

So I wonder what unnamed (say, malloc'ed) objects in C
are called? "referents"? "unnamed objects"? "doohickeys"?


-- 
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley

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

#59065

Robbie Hatley <see.my.sig@for.my.address> writes:
> On 3/22/2015 5:08 PM, James Kuyper wrote:
>> On 03/22/2015 07:39 PM, Keith Thompson wrote:
>> > What exactly do you mean by the word "variable"? ...
>>
>> A named object....
>
> I tend to agree. Perl also takes that tack. As for un-named
> objects (which abound in Perl), Perl calls them "referents".
>
> So I wonder what unnamed (say, malloc'ed) objects in C
> are called? "referents"? "unnamed objects"? "doohickeys"?

They're called objects.  In C, an "object" is by definition a "region of
data storage in the execution environment, the contents of which can
represent values".  There's no particular distinction between named and
unnamed objects; an object's behavior is determined by its type, storage
class, and so forth.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#59059

On 3/22/2015 3:47 PM, James Kuyper wrote:

> Can you refer to $var after the end of the loop? If only the memory
> persists, rather than access to that memory through the variable name,
> then you can't properly say that the variable persists. If you can
> access the memory through $var after the loop, which of the ten
> different addresses given does it refer to?

Perl is ref-counted, so if you repeatedly alter a variable, save
a reference, alter the variable, save a reference, etc, during a
loop, then multiple "snapshots" of the variable will be created.
When the loop exists, the variable goes out of scope. BUT, the
snapshots remain, and the references you saved all point towards
those valid referents. Only when the references themselves go out
of scope will the referents be trashed by the garbage collector.

> I think that he C equivalent of this perl code would not look like
> Robbie Hatley's original code, but more like this:
>
> for(int i=1; i<=10; i++)
> {
>      int *var = malloc(sizeof *var);
>      *var = i;
>      array[i] = var;
> }

That's close. But there's no exact way of doing Perl-style
variables in C, because C "auto" variables go "poof" when
their enclosing scope is exited. Whereas, Perl "my" variables
do NOT go "poof" on going out-of-scope if their ref count
is > 0; the variable can no longer be referred-to by name,
but the underlying referent can be read/written by reference.

As for C's "malloc" and C++'s "new", I rarely use either,
because creating things on-the-fly requires that one remember
to DESTROY them on-the-fly when they're no longer needed,
lest the computer's RAM get clogged with zombies.

Which maybe explains why certain software (Mozilla's
Firefox comes to mind; and Disney's "Toontown Online"
game client was another example) cause one's RAM usage
to slowly, inexorably increase till RAM is full and
hard disk is thrashing. Too many malloc's without free's?

The only garbage collector in C is the programmer.
So if he keeps slopping garbage around without cleaning it up,
it accumulates. Much to the anger of the end user who has to
keep pushing the "Reset" button because his machine keeps
freezing up.



-- 
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley

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

#59064

Robbie Hatley <see.my.sig@for.my.address> writes:
[...]
> Perl is ref-counted, so if you repeatedly alter a variable, save
> a reference, alter the variable, save a reference, etc, during a
> loop, then multiple "snapshots" of the variable will be created.
> When the loop exists, the variable goes out of scope. BUT, the
> snapshots remain, and the references you saved all point towards
> those valid referents. Only when the references themselves go out
> of scope will the referents be trashed by the garbage collector.

That's true if the variable is defined inside the loop.  Each iteration
creates a new object, and saving a reference to it keeps it from
vanishing.

If the variable is defined outside the loop, grabbing a reference inside
the loop just gives you multiple references to the same object.

(Reminder: I'm talking about Perl, not C.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web