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

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

C scope and struct definitions

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

Contents

  C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-22 13:30 -0400
    Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-22 14:02 -0400
      Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-22 22:40 +0000
        Re: C scope and struct definitions Ben Pfaff <blp@cs.stanford.edu> - 2012-06-22 15:47 -0700
        Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-22 20:32 -0400
          Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-23 22:06 +0000
            Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-23 16:18 -0700
              Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-25 10:19 -0400
                Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-25 11:51 -0700
            Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-23 19:54 -0400
              Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-24 00:56 +0000
                Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-23 21:48 -0400
                  Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-24 06:03 +0000
                    Re: C scope and struct definitions nick_keighley_nospam@hotmail.com - 2012-06-25 00:05 -0700
                Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-23 19:25 -0700
                  Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-24 05:40 +0000
                    Re: C scope and struct definitions Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-24 10:47 +0200
                    Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-24 11:00 -0700
                      Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-25 03:53 +0000
                        Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-25 01:14 -0400
                        Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-24 22:38 -0700
                    Re: C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-25 11:03 -0400
                      Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-26 20:08 +0000
                        Re: C scope and struct definitions Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-26 23:21 +0200
                          Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-26 21:47 +0000
                            Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-26 18:05 -0400
                          Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-26 16:45 -0700
                            Re: C scope and struct definitions Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-27 08:26 +0200
                              Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-27 00:01 -0700
                              Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-27 06:57 -0400
                                Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-27 15:00 -0400
                                  Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-27 14:48 -0700
                                  Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-27 16:14 -0700
                                    Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-29 09:36 -0700
                                  Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-27 16:27 -0700
                                Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-27 12:03 -0700
                                Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-27 12:11 -0700
                              Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-27 15:53 -0700
                        Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-26 17:59 -0400
                          Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-26 22:18 +0000
                            Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-26 18:33 -0400
                            Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-26 17:22 -0700
                              Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-27 00:03 -0700
                            Re: C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-27 14:13 -0400
                              Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-27 12:15 -0700
                                Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-29 09:43 -0700
                                  Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-29 11:59 -0700
                                    Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-01 18:32 -0700
                              Re: C scope and struct definitions pacman@kosh.dhis.org (Alan Curry) - 2012-06-27 20:59 +0000
                                Re: C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-28 16:42 -0400
              Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-23 20:57 -0400
                Re: C scope and struct definitions Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-23 22:11 -0400
                  Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-23 22:51 -0400
                    Re: C scope and struct definitions Nick Bowler <nbowler@draconx.ca> - 2012-06-25 17:31 +0000
                      Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-25 14:46 -0400
                        Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-25 14:43 -0700
                        Re: C scope and struct definitions Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-26 13:44 +0200
                  Re: C scope and struct definitions Keith Thompson <kst-u@mib.org> - 2012-06-23 20:07 -0700
                Re: C scope and struct definitions Jens Gustedt <jens.gustedt@loria.fr> - 2012-06-24 10:56 +0200
                  Re: C scope and struct definitions James Kuyper <jameskuyper@verizon.net> - 2012-06-24 08:29 -0400
                Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-24 10:26 -0700
            Re: C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-25 10:50 -0400
        Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-24 09:23 -0700
          Re: C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-25 11:17 -0400
            Re: C scope and struct definitions Tim Rentsch <txr@alumni.caltech.edu> - 2012-06-25 14:22 -0700
    Re: C scope and struct definitions Kenneth Brody <kenbrody@spamcop.net> - 2012-06-25 11:11 -0400

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#22643

pacman@kosh.dhis.org (Alan Curry) writes:
> In article <lnpq8o7fp7.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>>
>>Out of curiosity, are you talking about how you wish the language
>>had been defined in the first place, or are you proposing a change
>>to a future version of the language?
>
> Neither. I only said that I don't think limited scopes for struct definitions
> are useful, and there came a storm of disagreement. And also I speculated
> that application of scoping rules to type names is a historical accident
> rather than an intentionally designed feature, and I still don't know of any
> evidence for or aginst that idea.

Types and objects have the same scoping rules because giving them
different rules would make the language more complicated with, in my
opinion, little or no benefit.

> At least most of us agreed that a struct definition with "function prototype
> scope" is a bad sign.

Agreed. As discussed, C++ bans such definitions; I wouldn't mind if C
did the same.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#22687

On 6/24/2012 1:40 AM, Alan Curry wrote:
> In article <lny5nd78em.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>> pacman@kosh.dhis.org (Alan Curry) writes:
[...]
>>> Variable scopes make sense because the object named by the variable doesn't
>>> exist until the function is called. A type isn't an object.
>>
>> Are you conflating scope and lifetime?
>
> Are you seriously saying they aren't (or shouldn't be) closely tied together?

I don't think they are tied together at all.

I was going to say that the exception would be that a lifetime can't extend 
beyond a scope, but then thought of:

     void foo(void)
         {
         static struct bar { ... } foobar;
         ...
         }

Can you give an example where scope and lifetime are (or "should") be 
closely tied together?

-- 
Kenneth Brody

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

#22826

In article <Nv6dnf0QUclO4HXSnZ2dnUVZ_vadnZ2d@bestweb.net>,
Kenneth Brody  <kenbrody@spamcop.net> wrote:
>On 6/24/2012 1:40 AM, Alan Curry wrote:
>> In article <lny5nd78em.fsf@nuthaus.mib.org>,
>> Keith Thompson  <kst-u@mib.org> wrote:
>>> pacman@kosh.dhis.org (Alan Curry) writes:
>[...]
>>>> Variable scopes make sense because the object named by the variable doesn't
>>>> exist until the function is called. A type isn't an object.
>>>
>>> Are you conflating scope and lifetime?
>>
>> Are you seriously saying they aren't (or shouldn't be) closely tied together?
>
>I don't think they are tied together at all.
>
>I was going to say that the exception would be that a lifetime can't extend 
>beyond a scope, but then thought of:
>
>     void foo(void)
>         {
>         static struct bar { ... } foobar;
>         ...
>         }
>
>Can you give an example where scope and lifetime are (or "should") be 
>closely tied together?

Scope is the boundary of a variable's existence at compile time. Lifetime is
the boundary of a variable's existence at runtime. They're basically the same
thing in different dimensions (temporal at runtime, spatial at compile time).

And for local variables, they both default to the block enclosing the
declaration. At compile time, the variable can be referenced (i.e. its name
can be used) while that block is being parsed. At runtime, the variable can
be referenced (i.e. its value can be loaded from memory) while that block is
active.

static locals break that nice symmetry between compile time and runtime, in
the same way as the localized type definitions we've been talking about. And
they are inessential for the same reason: if you pull foobar out of the
function and give it a unique name, everything works exactly the same.

This is not an attack, a proposal, or a demand for anyone to stop using
"static". I know that's how things get interpreted by the more aggressive
posters here. So calm down everybody, not everything has to be a fight. I
have lots of local static variables in my own code. They don't feel as weird
to me as local types for some reason I can't explain.

Between nested functions, static local variables, and locally-scoped struct
definitions, the only one whose absence couldn't be easily worked around is
the one that's actually absent.

-- 
Alan Curry

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

#22831

Am 26.06.2012 22:08, schrieb Alan Curry:
> Scope is the boundary of a variable's existence at compile time.

of the identifier, to be precise

> Lifetime is
> the boundary of a variable's existence at runtime. They're basically the same
> thing in different dimensions (temporal at runtime, spatial at compile time).

no, not at all. Lifetime is a property of objects, not of
variables. Many objects aren't related to any kind of scope, are not
related to variables or identifiers, namely those that are allocated
through malloc and friends.

An object that is designated by a local variable in some function
scope, can be accessed in many scopes that are not related to the
scope of definition, simply by passing the address to another
function.

If a function is called recursively, many "incarnations" of the same
variable exist simultaneously. Multiple lifetimes correspond to a
single syntactical scope.

Jens

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

#22832

In article <4FEA27EC.70201@loria.fr>,
Jens Gustedt  <jens.gustedt@loria.fr> wrote:
>Am 26.06.2012 22:08, schrieb Alan Curry:
>> Scope is the boundary of a variable's existence at compile time.
>
>of the identifier, to be precise

If you're too precise about everything, you miss a lot. Like the fact that
"the variable exists here" is a reasonable way to describe the name being in
scope, and it's also a way to describe the memory region being allocated. Try
to actually *think* about it, instead of rephrasing it in language-lawyer
terms.

-- 
Alan Curry

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

#22834

On 6/26/2012 5:47 PM, Alan Curry wrote:
> In article <4FEA27EC.70201@loria.fr>,
> Jens Gustedt  <jens.gustedt@loria.fr> wrote:
>> Am 26.06.2012 22:08, schrieb Alan Curry:
>>> Scope is the boundary of a variable's existence at compile time.
>>
>> of the identifier, to be precise
>
> If you're too precise about everything, you miss a lot. Like the fact that
> "the variable exists here" is a reasonable way to describe the name being in
> scope, and it's also a way to describe the memory region being allocated. Try
> to actually *think* about it, instead of rephrasing it in language-lawyer
> terms.

     One thing you miss a lot of is opportunity to be misunderstood.
There's glory for you!

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#22838

Jens Gustedt <jens.gustedt@loria.fr> writes:
> Am 26.06.2012 22:08, schrieb Alan Curry:
>> Scope is the boundary of a variable's existence at compile time.
> of the identifier, to be precise
>
>> Lifetime is
>> the boundary of a variable's existence at runtime. They're basically the same
>> thing in different dimensions (temporal at runtime, spatial at compile time).
>
> no, not at all. Lifetime is a property of objects, not of
> variables. Many objects aren't related to any kind of scope, are not
> related to variables or identifiers, namely those that are allocated
> through malloc and friends.
[...]

What exactly do you mean by "variable"?

I tend to think of it as an informal word referring to a (probably
non-const) object that has a name, but I don't think that's how you're
using it.

I'm not saying your usage is wrong, but since the C standard doesn't
define "variable" I really can't tell what you mean by it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#22849

Am 27.06.2012 01:45, schrieb Keith Thompson:
> Jens Gustedt <jens.gustedt@loria.fr> writes:
>> Am 26.06.2012 22:08, schrieb Alan Curry:
>>> Scope is the boundary of a variable's existence at compile time.
>> of the identifier, to be precise
>>
>>> Lifetime is
>>> the boundary of a variable's existence at runtime. They're basically the same
>>> thing in different dimensions (temporal at runtime, spatial at compile time).
>>
>> no, not at all. Lifetime is a property of objects, not of
>> variables. Many objects aren't related to any kind of scope, are not
>> related to variables or identifiers, namely those that are allocated
>> through malloc and friends.
> [...]
> 
> What exactly do you mean by "variable"?

I refer to it as non-normative term that is used in the standard to
refer to an identifier with object type.

> I tend to think of it as an informal word referring to a (probably
> non-const) object that has a name, but I don't think that's how you're
> using it.
> 
> I'm not saying your usage is wrong, but since the C standard doesn't
> define "variable" I really can't tell what you mean by it.

It doesn't define it but it uses it in footnotes and non-normative
text at several occasions. From these uses I think the indended
meaning is pretty clear.

My point was that scope and lifetime are quite diffent concepts
because they are properties of completely different objects.

I don't think that this discussion will lead us much further.

Jens

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

#22851

Jens Gustedt <jens.gustedt@loria.fr> writes:
> Am 27.06.2012 01:45, schrieb Keith Thompson:
[...]
>> What exactly do you mean by "variable"?
>
> I refer to it as non-normative term that is used in the standard to
> refer to an identifier with object type.

That makes it sound like an identifier, not the object it refers to, is
a "variable".  Was that your intent?  The uses of "variable" in the
standard (in non-normative text) clearly refer to objects, not
identifiers.

>> I tend to think of it as an informal word referring to a (probably
>> non-const) object that has a name, but I don't think that's how you're
>> using it.
>> 
>> I'm not saying your usage is wrong, but since the C standard doesn't
>> define "variable" I really can't tell what you mean by it.
>
> It doesn't define it but it uses it in footnotes and non-normative
> text at several occasions. From these uses I think the indended
> meaning is pretty clear.
>
> My point was that scope and lifetime are quite diffent concepts
> because they are properties of completely different objects.

Agreed (though I'd say "entities" rather than "objects"; identifiers
have scope, and objects have lifetime).

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#22858

On 06/27/2012 02:26 AM, Jens Gustedt wrote:
> Am 27.06.2012 01:45, schrieb Keith Thompson:
...
>> What exactly do you mean by "variable"?
> 
> I refer to it as non-normative term that is used in the standard to
> refer to an identifier with object type.

Terms can't be normative, only statements can be normative. Identifiers
identify things, and the things that they identify may have a type, but
identifiers themselves do not. Personally, I use the definition "A
variable is a named object.". That definition fits every appearance of
the word "variable" as a noun in the C99 standard; I haven't checked yet
whether that's still true for C2011.
-- 
James Kuyper

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

#22885

On 06/27/2012 01:33 PM, Stefan Ram wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> identifiers themselves do not. Personally, I use the definition "A
>> variable is a named object.".
> 
>   That would be too vague for my taste. For example, after
> 
> int a[3];
> 
>   one might say that »a[1]« was a variable, because someone
>   called it »joe«.

That's not a name that a C program can attach to a[1]. A C++ program
could do so using a reference, but this is comp.lang.c.

Outside of a C context, (if you can figure out what "int a[3]" might
mean outside of C context), if someone wants to use the name 'joe' for
a[1], I have no objection to calling it a variable.

>   A more important point is: Your definition makes being a
>   variable a property of objects: By your definition, a
>   variable is a /special kind of object/: an object that is
>   /named/. An object is given by a region of storage and a
>   type. Now, when such an object is given, can one determine
>   whether this given object is a variable by your definition?
>   Usually not, because there is no way to find names starting
>   at the object! (At run-time most names are lost, and at
>   compile time there are no objects yet, so names and objects
>   rarely seem to exist at the same time at all.)
>   So, my definition would choose a wording more like
>   »A variable is a /pair of a name and an object/, where
>   the name refers to the object[ and ...]«.
> 
>   However, the point remains: Variable are usually chosen
>   to talk about source code, even when the source code is
>   only written on paper and never ever executed at all, it
>   still can have variables. So why include those objects
>   in the definition of a variable at all, when they never
>   might come into existence?

I've never used the term "variable" to refer to anything other than the
object that might or might not come into existence, when the program is
running. When I want to refer to the identifier, rather than the object
it identifies, I'll use a phrase like "the variable's name"; which would
be a meaningless phrase if "variable" referred to the identifier, rather
than to the object it identifies.

>   Also, I am not sure whether to use »name« or »identifier«
>   above.
> 
>   Can an object have several names in C?
> 
> union u0
> { int a;
>   int b; };
> 
>   comes to my mind.

That's a good question.

>   How many variables are declared with
> 
> union u0 u;
> 
>   ? for example, 1, 2 or 3?
> 
>   When a variable is a »named object« an /object/ with several
>   names counts as /one/ variable. When a variable is /pair/ of
>   a name and an object, each name counts as /one/ variable in
>   this case.
> 
>   Do union member names count at all as variable names?

Yes. The only question is how many different variables there are. When
people are discussing how a term should be defined. I find it helpful to
focus on what you want to say, using the term. Can you think of
something you would want to say about a variable, that would be harder
(or easier) to say if a and b were different variables, than it would be
if they were considered a single variable?

I looked to the standard for some examples of how it uses the term. I
found one which would require a rewrite if 'a' and 'b' were considered
different variables: "A floating-point status flag is a system variable
..." (7.6p1). If the status flag were a member of a union, and if
different members of the same union with the same type were considered
different variables, then "a" would have to be changed to "one or more",
to cover the possibility that the flag was a union member.
Similarly, 7.17.2.1 p2: "Concurrent access to the variable being
initialized ..."; if it were a member of a union, and those members were
considered distinct variables, all three variables would be initialized
at the same time, so that would need re-wording too.

I stopped looking at that point, there may be more examples, in either
direction.

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

#22900

ram@zedat.fu-berlin.de (Stefan Ram) writes:
[...]
>   BTW: ISO/IEC 14882:2003(E) says:
>
>       »A variable is introduced by the declaration of an
>       object. The variable's name denotes the object.«

That's the 2003 C++ standard. The 2011 standard (as of the N3337 draft)
expands on that a bit:

    A *variable* is introduced by the declaration of a reference other
    than a non-static data member or of an object. The variable’s name
    denotes the reference or object.

I find that definition unsatisfying. It says how a variable is
introduced, and that it has a name, but it doesn't say what a
variable *is* -- which is exactly what a definition is supposed
to do.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#22905

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> James Kuyper <jameskuyper@verizon.net> writes:
>>I stopped looking at that point, there may be more examples, in either
>>direction.
>
>   If one searches for >>variable<< and then strips all uses of
>   >>variable length/argument/number<<, >>condition variable<<,
>   uses in footnotes, or uses related to concurrency and
>   >>system variables<<, what remains are 3 places:
>
>       - >>the "integer promotions" require that the abstract
>         machine promote the value of each variable to int size<<
>
>       - >>behavior, but the value of the variable cannot
>         be used until a proper value is stored in it.<<
>
>       - >>variable c should be declared as int.<<

Just more examples of sloppy use of language in the Standard
referring to the different notions involved here.  Conflating
them only adds to the confusion.

>   And it seems that >>variable<< can be replace by >>object<< in
>   these three cases.

I can't agree to that one.  For one thing, regions of memory
aren't declared.  For another thing, a single declaration can
refer to more than one region of memory, either at different
times, or at the same time in the case of recursive function
calls.  Most often the term "variable" refers to a static
notion, not a dynamic one;  for the latter, I think it's more
usual to say "an instance of the variable".

>   BTW: ISO/IEC 14882:2003(E) says:
>
>       >>A variable is introduced by the declaration of an
>       object. The variable's name denotes the object.<<

Unfortunately, more sloppy language.  A declaration inside
a function body normally corresponds to more than one
region of memory.  In many cases the distinction isn't
important, but in lots of other cases it is.  Again,
conflating the different terms raises the level of
confusion.

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

#22984

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>And it seems that >>variable<< can be replace by >>object<< in
>>>these three cases.
>>I can't agree to that one.  For one thing, regions of memory
>>aren't declared.
>
>   This criticism would apply to N1570 too, which, for
>   example, writes:
>
>       >>An object declared as type _Bool is large enough to
>       store the values 0 and 1<<.

Yes it would, and appropriately so.

>>Unfortunately, more sloppy language.
>
>   I agree that there often is sloppy language in both ISO
>   standards.

Yes, and when there is, the right thing to do is call them on it,
not pretend that the sloppy language makes sense or is a good way
to express things.  (That's just a statement of general principle,
I don't mean to say you are one of the pretenders.)

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

#22906

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>And ISO 2382-2 says:
>
>   >>ISO 2382<< is >>Information technology. Vocabulary<<,
>   but I should have chosen >>ISO 2382-7<< which is specifically 
>   >>Part 7: Computer programming<<. For >>variable<<, it refers to
>   >>Part 15: Programming languages<< which eventually gives:
>
>       >>variable - A quadruple, established by a declaration or
>       an implicit declaration, that consists of an identifier,
>       a set of data attributes, one or more addresses, and
>       data values, where the relationship between the
>       addresses and the data values may vary.<< 
>
>   One arrives at my >>pair of a name and an object<<, when on
>   considers that the other three parts of the quadruple in C
>   are already part of the notion of >>object<<.

No, this definition is different in an important way, in that a
variable (potentially) corresponds to several different regions
of memory, not a single region of memory.  The cited defintion
corresponds more naturally to a static notion of the term
"variable", which IME is how most developers use the term.
Something associated with a particular region of memory (ie,
an /object/) is more likely to be called "an instance of a
variable".

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

#22886

James Kuyper <jameskuyper@verizon.net> writes:
> On 06/27/2012 02:26 AM, Jens Gustedt wrote:
>> Am 27.06.2012 01:45, schrieb Keith Thompson:
> ...
>>> What exactly do you mean by "variable"?
>> 
>> I refer to it as non-normative term that is used in the standard to
>> refer to an identifier with object type.
>
> Terms can't be normative, only statements can be normative. Identifiers
> identify things, and the things that they identify may have a type, but
> identifiers themselves do not. Personally, I use the definition "A
> variable is a named object.". That definition fits every appearance of
> the word "variable" as a noun in the C99 standard; I haven't checked yet
> whether that's still true for C2011.

By "non-normative", I meant that neither the term nor its definition
appears in normative text in the standard.

"A variable is a named object" is a reasonable definition. On the
other hand, it implies that a const-qualified object is a "variable",
even though it can't vary. And I've seen enough inconsistent uses
of the word that I generally avoid it except in very simple and
obvious cases.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#22888

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> James Kuyper <jameskuyper@verizon.net> writes:
>>identifiers themselves do not. Personally, I use the definition "A
>>variable is a named object.".
>
>   That would be too vague for my taste. For example, after
>
> int a[3];
>
>   one might say that »a[1]« was a variable, because someone
>   called it »joe«.

It seems sufficiently obvious to me that "named" means that the object
has a name (which is a single identifier) in the program text.

>   A more important point is: Your definition makes being a
>   variable a property of objects: By your definition, a
>   variable is a /special kind of object/: an object that is
>   /named/. An object is given by a region of storage and a
>   type. Now, when such an object is given, can one determine
>   whether this given object is a variable by your definition?
>   Usually not, because there is no way to find names starting
>   at the object! (At run-time most names are lost, and at
>   compile time there are no objects yet, so names and objects
>   rarely seem to exist at the same time at all.)

Yes, but I don't see that as a problem. In a running program, it doesn't
matter whether a given object is a "variable" or not; there's no need to
have a way to determine this.

We just use the word "variable" to refer to a named object, as in:

    int x; /* define an int variable named "x" */

>   So, my definition would choose a wording more like
>   »A variable is a /pair of a name and an object/, where
>   the name refers to the object[ and ...]«.

Hmm. I've always thought of a "variable" as a kind of
object. Applying it to a "pair of a name and an object", as you
suggest, seems (a) counterintuitive, and (b) not particularly useful.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#22904

Jens Gustedt <jens.gustedt@loria.fr> writes:

> Am 27.06.2012 01:45, schrieb Keith Thompson:
>> Jens Gustedt <jens.gustedt@loria.fr> writes:
>>> Am 26.06.2012 22:08, schrieb Alan Curry:
>>>> Scope is the boundary of a variable's existence at compile time.
>>> of the identifier, to be precise
>>>
>>>> Lifetime is
>>>> the boundary of a variable's existence at runtime. They're basically the same
>>>> thing in different dimensions (temporal at runtime, spatial at compile time).
>>>
>>> no, not at all. Lifetime is a property of objects, not of
>>> variables. Many objects aren't related to any kind of scope, are not
>>> related to variables or identifiers, namely those that are allocated
>>> through malloc and friends.
>> [...]
>> 
>> What exactly do you mean by "variable"?
>
> I refer to it as non-normative term that is used in the standard to
> refer to an identifier with object type.
>
>> I tend to think of it as an informal word referring to a (probably
>> non-const) object that has a name, but I don't think that's how you're
>> using it.
>> 
>> I'm not saying your usage is wrong, but since the C standard doesn't
>> define "variable" I really can't tell what you mean by it.
>
> It doesn't define it but it uses it in footnotes and non-normative
> text at several occasions. From these uses I think the indended
> meaning is pretty clear.
>
> My point was that scope and lifetime are quite diffent concepts
> because they are properties of completely different objects.
>
> I don't think that this discussion will lead us much further.

Let's see if some clarity can be added, and some of the
confusion removed.

First, the Standard is guilty of sloppy use of languge, or at
the very least some level of abuse of language, resulting in
statements that are confusing or even downright inconsistent.

There actually are four distinct notions involved here:

  1. A name, which is to say a sequence of letters (also
     numbers, and counting _ as a letter).  In the Standard
     such a sequence is defined as an /identifier/.

  2. An entity referred to by such a name, with the caveat
     that a particular name may refer to different entities
     at different points in the program text.

  3. An instance, or some might say instantiation, of an
     entity (of the sort mentioned in (2)), corresponding to
     a new activation of a function body or block.  In some
     cases it's unclear whether such "new copies" should be
     considered another instance of the same entity, or a
     new, different, entity in its own right, but that
     ambiguity needn't bother us too much for the present
     discussion.

  4. In the case of entities corresponding to something with
     an 'object type', the region of memory used to hold the
     stored value for (one instance of) said entity.  In the
     Standard such a region of memory is defined using the
     term /object/.

A big problem is that the Standard is careless in its use of
language when talking about these different notions.  For
example, sometimes /identifier/ is used only for notion 1,
and other times it is used also (or instead) for notion 2.
Similarly, sometimes /object/ is used only for notion 4,
and other times it is used for notion 3, or even notion 2!
For example, in 6.2.4 p6, the Standard says

    If the block is entered recursively, a new instance of
    the object is created each time.

Clearly that's absurd.  The program doesn't create a new instance
of a region of memory;  what it does do is allocate a /different/
region of memory, and associates that different memory object
with a new instance of the entity declared in the body of the
function defintion.

Considering the above, it's obviously pretty hopeless to use
terminology "the same way it is used in the Standard", unless
we diligently police ourselves to be as careful as the Standard
is careless.  (And even then it isn't easy...)

However, it is now easy to identify (umm.. no pun intended)
what most developers mean by the term "variable".  Or I
should say, what I think they mean, but if someone else has
a different ideas there is now clear language to express
that.  To give a somewhat abstract example:

    int
    foobas(){
        int i, j, k;
        ...
        while( ... ){
            int i, j;
            ...
        }

        ...
        return  i;
    }

Here we have an ordinary function definition, assuming of
course the ...'s are filled in with suitable additional
statements or expressions as necessary.  This code fragment
has four /identifier/s (not counting the keywords 'int',
'while' and 'return'): 'foobas', 'i', 'j', 'k'.  There are
five entities (in the notion 2 sense) in the function body,
one for each declarator in the two declarations.  Each
entity has a new instance (in the notion 3 sense) created
each time its corresponding block is entered (and so a
particular entity may have multiple instances simultaneously
active if the function is entered recursively).  For each
instance there is allocated a corresponding region of memory
(ie, an /object/) -- used to hold the stored value for that
instance of the entity in question.

Looking at this example, I think most developers would say
that the function body here has five variables, ie, one for
each notion 2 "entity", irrespective of whether the function
can be called recursively or not.  Any use of the variable
identifiers i, j, or k (assuming no interference from other
intervening declarations) will refer to one of those five
variables, with the mapping depending on just where in the
function body the use is.  Elaborating, the function body has
five variables whether it is ever called or not (or indeed
whether the program is ever run or not).  If the function
foobas() is called exactly once, three of those variables will
be instantiated once, and two will be instantiated zero or
more times, depending on how many times the while loop body
is executed.  For every instantiation of a variable, one
region of memory (ie, /object/) is set aside for the lifetime
of that instance of the entity.

Now, other people may have a different idea about what the
term "variable" should mean, and that's perfectly okay.  But
does anyone have a problem with the four different kinds of
notions outlined above used to explain how different terms
might be defined/used?

(P.S. I haven't taken the time to compile an exhaustive list of
all the different ways and places that the Standard uses the
terms /identifier/ and /object/.  However, the description
given above certainly matches how these terms are _defined_ in
the Standard, and also matches some important uses.  If someone
wants to quibble about the meaning of one of these terms "in
the Standard", please have something more significant to say
than "in paragraph xyz it's used to mean <blah>".  I know that
already - that is exactly my point in talking about sloppy
use of language in the Standard.)

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

#22833

On 6/26/2012 4:08 PM, Alan Curry wrote:
> In article <Nv6dnf0QUclO4HXSnZ2dnUVZ_vadnZ2d@bestweb.net>,
> Kenneth Brody  <kenbrody@spamcop.net> wrote:
>> On 6/24/2012 1:40 AM, Alan Curry wrote:
>>> In article <lny5nd78em.fsf@nuthaus.mib.org>,
>>> Keith Thompson  <kst-u@mib.org> wrote:
>>>> pacman@kosh.dhis.org (Alan Curry) writes:
>> [...]
>>>>> Variable scopes make sense because the object named by the variable doesn't
>>>>> exist until the function is called. A type isn't an object.
>>>>
>>>> Are you conflating scope and lifetime?
>>>
>>> Are you seriously saying they aren't (or shouldn't be) closely tied together?
>>
>> I don't think they are tied together at all.
>>
>> I was going to say that the exception would be that a lifetime can't extend
>> beyond a scope, but then thought of:
>>
>>      void foo(void)
>>          {
>>          static struct bar { ... } foobar;
>>          ...
>>          }
>>
>> Can you give an example where scope and lifetime are (or "should") be
>> closely tied together?
>
> Scope is the boundary of a variable's existence at compile time.

     Ah.  This is obviously some strange usage of the word "scope"
that I hadn't previously been aware of.  More to the point, it's a
usage not found in section 6.2.1 of the Standard, which defines what
the word means in C.  One of the first things you'll notice about
that section is that the title is not "Scopes of variables" but
"Scopes of identifiers."  Scope is not a property of variables, but
a property of identifiers.  (In fact, the word "variable" does not
appear even once in that section.)

> Lifetime is
> the boundary of a variable's existence at runtime. They're basically the same
> thing in different dimensions (temporal at runtime, spatial at compile time).
> And for local variables, they both default to the block enclosing the
> declaration. At compile time, the variable can be referenced (i.e. its name
> can be used) while that block is being parsed. At runtime, the variable can
> be referenced (i.e. its value can be loaded from memory) while that block is
> active.

     Well, no.  Whenever an auto variable's identifier is in scope,
that identifier exists, yes.  But the opposite does not hold: Even
while the variable exists, its identifier can be out of scope.  (I
can think of three ways for this to happen; there may be others.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#22835

In article <jsdbb6$t43$1@dont-email.me>,
Eric Sosman  <esosman@ieee-dot-org.invalid> wrote:
>On 6/26/2012 4:08 PM, Alan Curry wrote:
>>
>> Scope is the boundary of a variable's existence at compile time.
>
>     Ah.  This is obviously some strange usage of the word "scope"
>that I hadn't previously been aware of.  More to the point, it's a

It's an explanation of the concept, in my own words, deliberately chosen to
not look like standardese. I did that because I believe if you can't explain
something in your own words, you don't really understand it.

>usage not found in section 6.2.1 of the Standard, which defines what
>the word means in C.  One of the first things you'll notice about
>that section is that the title is not "Scopes of variables" but
>"Scopes of identifiers."  Scope is not a property of variables, but
>a property of identifiers.  (In fact, the word "variable" does not
>appear even once in that section.)

The more you have to rely on word-for-word quotations from an authoritative
source, the less conceptual understanding you demonstrate.

A variable is a name, a value, an address, or some combination of those
possibilities, depending on when you look at it. When you're writing the code
(as opposed to compiling and running it), the variable is the name. If you
saw something like

  void foo(int i)
  {
    /*something*/
  }

  int bar(void)
  {
    return i;
  }

Wouldn't you think it's reasonable to say that the reason bar() won't compile
is that the variable i doesn't exist there? If you don't accept that wording,
then you're too much of a language lawyer to ever make sense of the way real
programmers talk.

>
>> Lifetime is
>> the boundary of a variable's existence at runtime. They're basically the same
>> thing in different dimensions (temporal at runtime, spatial at compile time).
>> And for local variables, they both default to the block enclosing the
>> declaration. At compile time, the variable can be referenced (i.e. its name
>> can be used) while that block is being parsed. At runtime, the variable can
>> be referenced (i.e. its value can be loaded from memory) while that block is
>> active.
>
>     Well, no.  Whenever an auto variable's identifier is in scope,
>that identifier exists, yes.  But the opposite does not hold: Even
>while the variable exists, its identifier can be out of scope.  (I
>can think of three ways for this to happen; there may be others.)

That's a fun puzzle. Shadowing of course, which is a "don't do that".
Preprocessor effects ruled out, I assume. Maybe a variant of shadowing in
which typedef is used in an inner block.

-- 
Alan Curry

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web