Keith said:
Keith said:
(e-mail address removed) writes:
Keith Thompson wrote:
(e-mail address removed) writes:
[...]
I would instead say, that a static *variable* is something either with
file scope (declared outside of any function) or an auto with a static
declaration. General static objects also include initialization values
with implicit storage (such as inline strings, and potential structs,
or unions that contain them, initialized to something other than an
array) and clearly have a value that is self declared rather than being
0.
I'm not sure this distinction between objects and "variables" is
useful. The standard carefully avoids defining what a "variable" is
(though it uses the word informally a few times).
Yeah, well the "standard" is not something from which you can derive
any true understanding of anything.
I certainly can. I don't know what your problem is.
That's like saying spelling bee champions are expert linguists. A
language standard that goes out of its way to avoid the word variable
seems to me like it maybe has been built on questionable premises.
Not really. The C standard uses the word "object", and describes
properties that objects have. I truly don't see how introducing the
word "variable" (presumably variables are a subset of objects?) would
be helpful.
Well, every single computer 101 student knows what variable is. It
means its a base of knowledge by which you have universal understanding
and agreement without question. It would be helpful because everyone
would know what you are talking about.
If you want a tough definition, try giving one for "object".
The fact that certain hunks of data can exist should be a seperate
concept to a variable it happens to be sitting in. A *variable* can
cause a hunk of data to inherit const semantics at run time while a
hunk of data intrinsically in of itsef cannot change its const
semantics. So this distinction kind of matters, and it means knowing
the difference between variables, and "objects" is a prerequisite for
"getting" this.
So for example, if you have an inline string, can you return it from a
function? It depends on the attributes of the *variable* it was first
bound to. It can be returned if it was stuck in a char *, but *not* if
it is stuck in a char[]. How does one think about this without
understanding that its through the variable declaration that we
determine this?
By understanding the attributes of the objects that the program is
operating on.
By "inline string", I assume you mean a string literal. A string
literal corresponds to a static object with certain attributes as
defined in the standard. If it's "stuck in a char*", then you have an
object of type char* that points to the object.
Well, more than that you have implicit storage. The inline string has
to actually exist as a wad of data somewhere.
[...] If it's "stuck in a
char[]", then you've copied the value of that object to another
object.
No, that's a matter of implementation.
char x[] = "xxxx";
is the same as
char x[];
memset (x, 'x', 4);
x[4] = '\0';
No, it isn't. The first form is legal; the second is not.
I think you mean:
char x[5];
memset(x, 'x', 4);
x[4] = '\0';
and a compiler might easily do that, without the requirement of the
existence of any "xxxx" "object" (actually, this is more likely with
char x[]="", for obvious reaons). Similarly, if you mismatch the size
of the array declaration with the inline string, the compiler has a
bunch of choices as to how to deal with the truncation or expansion of
the array, including the mutation of the representation of the inline
string where it is stored. Since there is no reference to the original
inline string, it does not actually have to exist, or have any property
you think it might have. There's no way for you to force the string
literal to have any particular manifestation you want it to outside of
a particular implementation.
Yes, in the case of
char x[] = "xxxx";
the compiler doesn't have to allocate storage for the string literal.
Meaning that calling "xxxx" an object doesn't really mean anything now
does it?
And how does calling x a "variable" rather than an "object" help
anything? x is an object that has certain properties, including a
type and a (current) value.
I think it would help the OP, who I am sure understands very clearly
what a variable is, but probably does not understand what an object is.
[...] If that object has automatic storage duration, then returning
a pointer to that object outside the object's scope can cause
undefined behavior; the origin of the value stored in that object is
no longer relevant.
This is all stuff that I learned from the standard.
Yes, but there is the question of what you didn't learn.
Of which I'm sure there's a lot. What is your point?
That the standard is not something from which you can derive
understanding.
Now you're just being insulting.
Well, I'll admit that that may have been my original intent, but in
reading your follow-up, it appears as though this point seems
startlingly applicable.
Of course I know, in general terms, what a variable is. That's not
what I asked. I said I don't know *what you mean* by "variable".
I mean what it means in general terms. The concept doesn't take
different meanings in different contexts of computer programming.
We're not talking about statistics or algebra here.
It is not obvious what the word "variable" should mean in the context
of C. For example:
int x;
/*
* Obviously x is a variable.
*/
Its independent, corresponds to storage, and its named. So yes, its a
variable.
int arr[10];
/*
* arr is a variable.
Yes.
* Is arr[0] a variable?
No. arr[0] is not independent of arr, and arr[0] is not a name. In C
you can apply "const" to variables. You cannot apply const to arr[0],
unless you also apply it to all of arr simultaneously.
*/
struct {
int x;
int y;
} s;
/*
* Is s.x a variable?
*/
Similarly to arr, s.x is not independent of s, and s.x is not a name.
const int c = 42;
/*
* Is c a variable?
Yes.
* It can't vary (unless you invoke undefined behavior).
This is about computer programming concepts, not word deconstruction.
* If c isn't a "variable", how useful is the word?
Well -- it *is* a variable. Its constant, but that's a semantic. I
mean what would you call a variable that only had one value throughout
its lifetime? Or which you can prove will only have one value? That
it varies or can legally vary is not a well defined criteria, and its
obviously not what constitutes a variable.
*/
int *ptr = malloc(sizeof *ptr);
/*
* Assuming ptr != NULL, is *ptr a variable?
No, *ptr is not a name, and its not independent of ptr.
*/
Replace "variable" by "object" in the above, and the answer to each of
these questions is clearly yes.
Replace it by "storage", and the answer is also yes. (Logical
reasoning is also a good thing to have if you plan on seriously
endeavouring to be a computer programmer.)
[...] other than that it's
apparently something distinct from an object. If you can provide a
rigorous definition of the word "variable", perhaps we can discuss
this.
Independent named storage? In C I guess it would be declared
independent named storage.
Independent of what?
Of other variables.
