M
Mark McIntyre
Thats fair enough.
Thats fair enough.
I
Irrwahn Grausewitz
Mark McIntyre said:
Apparently he's both, see below.
I had some spare time and did a quick google groups search. If you're
only interested in the highlights, do a search for threads that have his
name in the _subject-line_. For the full load perform a search for
articles he posted. It's real fun.
I still don't think so.
And miss the fun? Naw...
A
Arthur J. O'Dwyer
A pointer *is* either the address of an object, or the address
of a function, or the null pointer constant.
A pointer *may* not be an object, but it always is a *value*.
For example, (my_array+1) is not an object, nor is it a null
pointer, but it is still an expression of pointer type.
To be really clear (which I suppose one must), one should really
speak of "objects of pointer type" and "expressions of pointer
type." I don't think the Standard assigns any meaning to the
noun "pointer" itself, except as a kind of shorthand for
"object of pointer type" or "expression of pointer type." Just
like it doesn't make sense to speak of "a short int;" you can
speak of "an object of type 'short int'" or "a value of type
'short int'," but they're two different things whose only
commonality is their type.
-Arthur,
obviously *not* Roose
K
Keith Thompson
pete said:
The distinction here is between pointer objects and pointer values. A
pointer object can hold a pointer value. A pointer value is also
known as an address.
I
Irrwahn Grausewitz
pete said:
To dissolve this ambiguity one could differentiate between "pointer
variables" (which represent objects that can hold pointer values) and
"pointer values" which are ... err ... pointer values
K
Keith Thompson
Irrwahn Grausewitz said:
Does this refer to Richard or to me? If it's to me, be aware that the
UFO guy is a different Keith Thompson.
R
Richard Heathfield
Alan said:
I don't believe you. Please provide evidence to support that assertion.
Indeed it is, in common with several other of your recent articles. You owe
several people on this newsgroup an apology.
M
Mark McIntyre
I feel pretty comfortable that a pointer has to be an object.
Otherwise how could you point to it?
It might *contain* that, but it itself must be an object. I think....
P
pete
Mark said:
int a;
&a;
(&a) is a pointer, but not an object.
R
Richard Heathfield
Irrwahn said:To dissolve this ambiguity one could differentiate between "pointer
variables" (which represent objects that can hold pointer values) and
"pointer values" which are ... err ... pointer values
Problem: an object that holds a pointer value need not be a variable. For
example:
int i = 6;
int * const p = &i; /* p is not a variable - or at least, to persuade anyone
that it is, you'd have to have kissed the Blarney. */
L
Lew Pitcher
August said:
Funny thing is, those "old" machines are still cranking out the data. In my
employed life ([email protected]) I occasionally code in S/390 HLASM (High
Level Assembler) for production purposes. The last bit of Assembly code I
wrote provides COBOL programs the ability to read and write "Variable Blocked
Spanned" (or "VBS") files that have logical record lengths greater than 32767
bytes long. Such is the life of an industrial programmer (one who writes code
for industry, rather than as a commercial product).
Heh. I guess the fact that Z80 assembly was binary-compatible with
8080 didn't help you much, then?
Since Z80 Assembly has a different syntax than 8080 Assembly, and uses
different mnemonics, the fact that the 8080 instructionset was a subset of the
Z80 set didn't help much. One of my early accomplishments was to write a set
of macros for Microsoft Z80 Macro Assembler to permit me to write assembly
modules that could be linked to modules written in Leor Zolman's BDS C. I
wrote a simple multitasking monitor for C programs with those macros.
Never had the opportunity to work on a VAX.
I played with TOPS-10 on a PDP-10 while in High School, and a relative who
worked at DEC got me the Macro-10 manuals. I can't remember how I got the
manuals for the PDP-11 (11/70, IIRC), but they did include some information on
the instruction set.
Having read some of the histories, and taken a look at the PDP-11 instruction
set, I can readily understand how those early C language design decisions were
made.
Truly, C was designed to be somewhere between PDP-11 assembly and
PL/1, but closer to assembly in some key ways.
And I think learning PDP-8 assembly is what seperates the men from the
boys, esepcially if you can only use the 8 `actual' opcodes.
As a teen, I lusted after an Intersil CMOS PDP-11. I never even got close to
an '8. :-(
--
Lew Pitcher
Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
B
Ben Pfaff
Irrwahn Grausewitz said:To dissolve this ambiguity one could differentiate between "pointer
variables" (which represent objects that can hold pointer values) and
"pointer values" which are ... err ... pointer values
I think these are typically called "objects of pointer type" and
"values of pointer type". If you want to abbreviate their
monikers to "pointer objects" and "pointer values" then that's
fine by me.
R
Richard Heathfield
Keith said:
No, I'm fairly sure it refers to Alan Connor. Irrwahn is right, you know -
it's a very... well, see for yourself.
A likely story. ;-)
K
Keith Thompson
Richard Heathfield said:
Oh, my.
It's true. *beep* I come in peace. *beep*
S
Sheldon Simms
I suppose that depends on the definition of the word variable. Perhaps
this is why the C standard doesn't say much about "variables".
In any case, I would call p a variable - a const variable. If you're
speaking English, it's a contradiction, but we're speaking jargon.
This seems an opportune place to insert the rewritten first paragraphs
of my earlier post to Alan, the woefully misinformed. Comments are
welcome:
-------------------------------------
C Pointer Basics
Objects:
The C Standard defines an object as "a region of storage", that is, some
contiguous sequence of bytes in computer memory. An object has a size and
can store values. Objects also have a lifetime. An object can be created
and exist, and then later be destroyed and no longer exist.
Variables:
Variables can be thought of as named, typed, objects. A variable is declared
with a name and a type. Variables are also associated with some amount of
memory. That region of memory is an object -- the object named by the
variable.
Pointers:
A pointer is a kind of value that can "point to" some object. Most of the
pointers in a C program are usually values stored in pointer variables, that
is, a variable that has been declared with a pointer type.
There are also pointer values that are not stored in variables, and a special
kind of pointer called a null pointer, that, although it is a pointer does
not point to any object at all.
Pointers can be valid or invalid. A valid pointer has a value that points to
an existing object. An invalid pointer has a value that does not point to an
existing object. If a pointer is valid, and points to an existing object, and
the object is then destroyed, the pointer becomes invalid, for the object to
which it pointed no longer exists.
You might wonder what it means for a pointer to "point to" an object. It
means that it is possible to access the object by using the pointer to see
where it is.
For example, let an integer variable be declared in a C program:
int main (void)
{
int x; /* x: a variable of type int */
...
return 0;
}
The declaration causes the name x to become associated with a region of
memory. The region of memory is the object associated with the variable x.
x is also associated with a type, in this case the type of x is int. C
allows us to set and retrieve the value of the object named x:
#include <stdio.h>
int main (void)
{
int x; /* x: a variable of type int whose value is undefined */
x = 3; /* set the value stored in the object named x to 3 */
printf("x == %d\n", x); /* print the value of the object named x */
return 0;
}
This program will produce the output
x == 3
You might wonder why the comment in the sample code above verbosely reads
"set the value stored in the object named x to 3" instead of "set x to 3".
Although it is common for C programmers to abbreviate and say things like
"set x to 3", the comment above is written as it is because it is possible
to manipulate the object associated with x without actually using the name
x. It is important to understand that what is being changed is the value
stored in an object. Although x could be considered the "main" or "canonical"
name of the object, it can be referred to in other ways as well, and its
value can be set and retrieved using those other ways.
One other way of referring to the object named x is to use a pointer:
int main (void)
{
int x; /* x: a variable of type int */
int *p /* p: a variable of type pointer to int */
p = &x; /* make p point to the object named x */
...
return 0;
}
Now p is the name of a pointer that refers to the same object as x and we
can manipulate the value of the object named x by accessing that object
"through" the pointer named p.
#include <stdio.h>
int main (void)
{
int x; /* x: a variable of type int */
int *p /* p: a variable of type pointer to int */
p = &x; /* make p point to the object named x */
*p = 5; /* set the value of the object pointed to by p to 5 */
/* the object pointed to by p is the same as the object
named x. */
printf("x == %d\n", x);
printf("*p == %d\n", *p);
return 0;
}
This program will produce the output
x == 5
*p == 5
The value stored in the object named x has been altered by using p. The
object that p points to is the same as the object that is named x. This can
be said more succinctly "p points to x". However, p is not the same as x.
p is also the name of an object. That object has a type (pointer to int),
and a value of some kind. The value of p "refers to" the object named x, but
how it does that is of no concern to C programmers, all that is important is
that we can manipulate that value in certain ways.
To try to make this clear before talking more about the value of p, here's
a diagram that attempts to show the objects named p and x in memory
+-----------+
| (value)--+------+
+-----------+ | +-----------+
p: pointer to int +----->| 5 |
+-----------+
x: int
There is an object named p, and an object named x. The object named x has the
value 5 and the object named p has a value that points to x.
------------------------------------------
N
nobody
At least on something we can agree. Assassination of character of clcAlan Connor said:
(or attempt at it, anyway).
And I can't speak for others, by if by "we" you mean "Alan Connor"
and "Roose", then I think you are, if you are asking.
N
nobody
Above "pairing" fails for "strings", which I believe can attribute forArthur J. O'Dwyer said:
often mistakes of (mis)handling them (e.g. not allocating memory
for them, or calling strstr() on "binary" data returned from socket,
as can be often? witnessed in questions posted here).
There is only "a value of type 'string'", but no "object of type
'string'". Or am I wrong again? Is string value *and* object
at the same time and they are just identical, without "dichotomy"
of other types?
(That's why I try to avoid to use term "string" when
dealing with C and beginners, unfortunately to the point when
I've recently misleadingly stated /but fortunately was corrected/
that strings don't exist in C <ot> Is there any fitting idiom in English
for that? Something like "falling into one's own trap" ? </ot>).
A
Alan Connor
ROTFL that came across perfectly on my configuration of slrn:
The beeps (no asterisks visible) were in bright blue-bold and the rest of the
text in grey.
K
Keith Thompson
Sheldon Simms said:
That's interesting. I just searched the C standard for the word
"variable". It uses the term informally in informative text (notes
and examples), and as an adjective (variable-length arrays, variable
argument lists). The only other uses are in the description of the
for statement ("If clause-1 is a declaration, the scope of any
variables it declares is the remainder of the declaration and the
entire loop, including the other two expressions ...") and <fenv.h>
("A floating-point status flag is a system variable ...."). Both of
these are new to C99, which makes me suspect that the original intent
was not to use the term "variable" in its usual sense.
Hmm. Since the C standard doesn't define the term "variable", I'd
prefer to use it in its normal English sense, which would exclude
objects whose value cannot be modified.
R
Richard Heathfield
Keith said:
That is precisely how I use it. I'm aware of this strange idea of "const
variable". I think it's easier and more useful to talk about objects.