473,324 Members | 2,268 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

Good Tutorials

75 3303
Flash Gordon wrote:
Amkcoder wrote, On 23/09/08 17:50:

<snip>
This leads to another mistake in your tutorial. You say...
>The address of memory allocated by a declared variable may be retrieved
with the address of operator for assignment to a pointer, or for
later storage.
This works on any variable but pointers, if it is a pointer one
may retrieve the address it holds by excluding the asterik prefixed
to its identifier.

This is wrong.
Very wrong.

To "retrieve the address it holds",
neither an ampersand nor an asterisk is used.

The asterisk is used to reference the value of the object
that the pointer points to.
The address operator "&" works perfectly well on pointer
variables, I know because the standard says so and I use it.
--
pete
Sep 24 '08 #51
pete <pf*****@mindspring.comwrites:
[...]
To "retrieve the address it holds",
neither an ampersand nor an asterisk is used.

The asterisk is used to reference the value of the object
that the pointer points to.
[...]

Or to refer to the object itself; unary * yields an lvalue.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 24 '08 #52
On 24 Sep, 17:46, Keith Thompson <ks...@mib.orgwrote:
Nick Keighley<nick_keighley_nos...@hotmail.comwrites:
On 23 Sep, 18:21, Richard<rgr...@gmail.comwrote:
This constant desire to confuse people with a "pointer is not an
address" is simply ridiculous. It is an "address". You address an object
or memory or whatever through it. One representation of that address is
as a value which can be displayed as a hexadecimal memory "address".
this was wrong the first time you said it. It is still wrong.

Um, how is it wrong?

A pointer is an address; the way the standard defines the terms,
they're nearly synonymous (though I suspect Richard is using the term
"address" in some more hardware-specific way). *And it's always
possible to represent a pointer value / address in hexadecimal; even
if "%p" doesn't do this, you can interpret its representation as an
array of unsigned char.

An address is not a number (though it's often implemented that way),
but Richard didn't make that particular claim here.
yes. I meant "a pointer is not a number" rather than "a pointer
is not an address". I interpreted "it's always possible to represent
a pointer value / address in hexadecimal" as "a pointer is a number".
--
Nick Keighley

Sep 25 '08 #53
Nick Keighley <ni******************@hotmail.comwrites:
On 24 Sep, 17:46, Keith Thompson <ks...@mib.orgwrote:
>Nick Keighley<nick_keighley_nos...@hotmail.comwrites:
On 23 Sep, 18:21, Richard<rgr...@gmail.comwrote:
>This constant desire to confuse people with a "pointer is not an
address" is simply ridiculous. It is an "address". You address an object
or memory or whatever through it. One representation of that address is
as a value which can be displayed as a hexadecimal memory "address".
this was wrong the first time you said it. It is still wrong.

Um, how is it wrong?

A pointer is an address; the way the standard defines the terms,
they're nearly synonymous (though I suspect Richard is using the term
"address" in some more hardware-specific way). Â*And it's always
possible to represent a pointer value / address in hexadecimal; even
if "%p" doesn't do this, you can interpret its representation as an
array of unsigned char.

An address is not a number (though it's often implemented that way),
but Richard didn't make that particular claim here.

yes. I meant "a pointer is not a number" rather than "a pointer
is not an address". I interpreted "it's always possible to represent
a pointer value / address in hexadecimal" as "a pointer is a number".
So where was I wrong?

And and address on MOST platforms IS represented as a number ....

This whole issue is somewhat silly.
Sep 25 '08 #54
Richard<rg****@gmail.comwrites:
Nick Keighley <ni******************@hotmail.comwrites:
>On 24 Sep, 17:46, Keith Thompson <ks...@mib.orgwrote:
>>Nick Keighley<nick_keighley_nos...@hotmail.comwrites:
On 23 Sep, 18:21, Richard<rgr...@gmail.comwrote:
>>This constant desire to confuse people with a "pointer is not an
address" is simply ridiculous. It is an "address". You address an object
or memory or whatever through it. One representation of that address is
as a value which can be displayed as a hexadecimal memory "address".

this was wrong the first time you said it. It is still wrong.

Um, how is it wrong?

A pointer is an address; the way the standard defines the terms,
they're nearly synonymous (though I suspect Richard is using the term
"address" in some more hardware-specific way). Â*And it's always
possible to represent a pointer value / address in hexadecimal; even
if "%p" doesn't do this, you can interpret its representation as an
array of unsigned char.

An address is not a number (though it's often implemented that way),
but Richard didn't make that particular claim here.

yes. I meant "a pointer is not a number" rather than "a pointer
is not an address". I interpreted "it's always possible to represent
a pointer value / address in hexadecimal" as "a pointer is a number".

So where was I wrong?
Where you claimed that there was a 'constant desire to confuse people
with a "pointer is not an address"'. That claim is never made by
knowledgeable posters and I have seem Keith Thompson correct it a
couple of time when it is made by people who are obviously already
confused. Nobody that you would call a "reg" makes it and none of
them have a desire to confuse people by introducing such a falsehood.
And and address on MOST platforms IS represented as a number ....
Stick with that and I doubt there will be much dissent.

--
Ben.
Sep 25 '08 #55
Hello Richard, James, List

On Sep 24, 7:03 am, Richard Heathfield <r...@see.sig.invalidwrote:
soscpd said:
A teacher should never try to tell the whole truth (because there isn't
time
And, maybe: "..., neither whole truth..." :-)
On Sep 24, 7:28 am, James Kuyper <jameskuy...@verizon.netwrote:
soscpd wrote:
Technical jargon serves many purposes, including the ignoble purpose of
separating the in-group and the out-group. However, it's main purpose is
to clearly communicate complex concepts ...
Yes indeed.
I suspect that you actually understand the difference those words
Yes, I did.
describe; I just think you're unclear about the fact that those words
describe that difference.
Hey... I did understand that too.
The difference is that a pointer object is a piece of memory
Here is, probably, my real problem. As far as my knowledge can lead
me, a pointer is an address to the beginning of a memory location.
That, in my words, make the pointer to not be ever a value. Knowing
the correct address (same to say - having the correct pointer), I can
explore (I know, with undefined consequences) any "in memory" value/
object/whatever.

Due to optimization, that pointer value might never be stored anywhere -
p+3 might be combined with some other operation, as in (p+3)->count.
Hey... "anywhere" is one of the powerful stuff about pointers.
That C code might be translated into machine code which retrieves the
byte address stored in p, and then adds to it, in a single instruction,
the combined values of 3*sizeof *p and the offset of the 'count' member
within the struct pointed at by p.
Ok.
The distinction between a pointer object and a pointer value is
....
Ok... taking the words object and value, a pointer object is the
pointer itself. Pointer value is the (address - beginning of the)
memory location who the pointer point's to. You will, then, use the
memory contents from pointer address to sizeof pointer type * n (where
n should be unsigned int 0). If not... how can a void type ever
exists?

I mean... the only possible value of a pointer is a memory location,
right? The memory content's and how to handle it should be another
subject, IMHO.

Thanks
Rafael
Sep 25 '08 #56
soscpd wrote:
Hello Richard, James, List
....
>The difference is that a pointer object is a piece of memory

Here is, probably, my real problem. As far as my knowledge can lead
me, a pointer is an address to the beginning of a memory location.
A pointer value is the memory location itself. A pointer value can be
represented in a pointer object by the machine address of that location.
That, in my words, make the pointer to not be ever a value.
I don't understand why you would say that. The value of an object is,
always, an abstract thing, like the number 3. The contents of the
object, on the other hand, are concrete things like bits which are
either turned on or off, in a pattern which represents the value. This
is precisely the same relationship that exists between the value of a
pointer and the bit pattern that ist stored in a pointer object.
... Knowing
the correct address (same to say - having the correct pointer), I can
explore (I know, with undefined consequences) any "in memory" value/
object/whatever.

>Due to optimization, that pointer value might never be stored anywhere -
p+3 might be combined with some other operation, as in (p+3)->count.

Hey... "anywhere" is one of the powerful stuff about pointers.
Yes, and despite the power of pointers, no pointer can point at the
location where the value of p+3 is stored, during the evaluation of
(p+3)->count.

Sep 25 '08 #57

"soscpd" <so****@gmail.comwrote in message
news:ac**********************************@8g2000hs e.googlegroups.com...

I mean... the only possible value of a pointer is a memory location,
right? The memory content's and how to handle it should be another
subject, IMHO.
A pointer can have a whole bunch of values that are not memory locations.

Maybe the memory simply doesn't exist. Or is outside an allowed range. Or
the value might be valid for one type of target but not for another (for
example a pointer to a word might require an 'even' pointer value, or the
targets exist in different memory spaces).

And sometimes, you might have different pointer values addressing the same
memory location.

--
Bartc

Sep 25 '08 #58
Hello James, Bartc, List

On Sep 25, 8:45 am, James Kuyper <jameskuy...@verizon.netwrote:
A pointer value is the memory location itself.
My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?
That, in my words, make the pointer to not be ever a value.
I don't understand why you would say that. The value of an object is,
always, an abstract thing, like the number 3.
The pointer value or object will never be 3 (sorry about "will not be
ever a value". What I mean is - the pointer value will never be 3, in
that case). It will be the address of a memory location. The memory
location will have the desired value (well... that depends of what you
are looking for).
On Sep 25, 8:57*am, "Bartc" <b...@freeuk.comwrote:
A pointer can have a whole bunch of values that are not memory locations.
Yes... that is exactly the thing I can't figure. Isn't the point a
address to the value? Or is the pointer the value itself?

Maybe the memory simply doesn't exist. Or is outside an allowed range.
Please, define allowed. You mean, allowed for defined behavior?

the value might be valid for one type of target but not for another
Agreed. But that is not part of the (pointer) subject, IMHO.
Why we need to mix the pointer with the memory contents the pointer
point's to? There are too many possible values. Maybe understanding
pointers just as the address to memory locations will make our lifes
easy.

Through pointers, we can:
Reserve/Release some reserved memory(malloc & cia);
Point to some memory location (doesn't matter what is inside, except
if yu will use it);
Get whatever from reserved space (so, read memory from pointer to
sizeof(data));
Assign whatever to reserved space (or not reserved space - UB);
....

I just don't know if it is true (by the book. Using it just like that
works very fine... so far :-).

Regards
Rafael

Sep 25 '08 #59
soscpd <so****@gmail.comwrote:
On Sep 25, 8:45 am, James Kuyper <jameskuy...@verizon.netwrote:
A pointer value is the memory location itself.

My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?
Not necessarily. First, "address" can mean a lot more than just "index
into one giant pool of memory". And then a pointer is allowed to hold
more information than just the address itself. It can hold the size of
the memory block, to detect memory overflow, in debugging
implementations. Or it can hold the type of the object pointed at. That
needs a bit of fiddling with void *s, but it's possible.

Richard
Sep 25 '08 #60
soscpd wrote:
>
.... snip ...
>
Here is, probably, my real problem. As far as my knowledge can
lead me, a pointer is an address to the beginning of a memory
location. That, in my words, make the pointer to not be ever a
value. Knowing the correct address (same to say - having the
correct pointer), I can explore (I know, with undefined
consequences) any "in memory" value/ object/whatever.
No you can't. If you try to 'explore' beyond the bounds of the
object the pointer originally pointed to, or within, the result is
undefined behaviour. Any defined action is system specific.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Sep 25 '08 #61
soscpd <so****@gmail.comwrites:
Hello James, Bartc, List

On Sep 25, 8:45 am, James Kuyper <jameskuy...@verizon.netwrote:
>A pointer value is the memory location itself.

My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?
That, in my words, make the pointer to not be ever a value.
I don't understand why you would say that. The value of an object is,
always, an abstract thing, like the number 3.

The pointer value or object will never be 3 (sorry about "will not be
ever a value". What I mean is - the pointer value will never be 3, in
that case). It will be the address of a memory location. The memory
location will have the desired value (well... that depends of what you
are looking for).
[...]

The word "pointer", by itself, is ambiguous; it can refer either to a
pointer object or a pointer value. A pointer value is also called an
"address". (Well, mostly, I'm not sure that a null pointer value or
an indeterminate pointer value is an "address".)

You can also have a pointer type, such as int*.

To understand the distinction, let's look at integers. Again, the
word "integer" by itself could mean either an integer object, or an
integer value, or maybe an integer type. Concretely:

int x = 42;

x is an integer object. 42 is an integer value. int is an integer
type (one of several defined by the language). These are closely
related: int is the type of the integer object x, and of the integer
value 42, and 42 is the current value of the integer object x. An
integer *value* can be either the current value of an integer object,
or the result of evaluating an integer expression; the latter isn't
necessarily stored anywhere. If the value 42 is stored somewhere, it
will be represented as a sequence of bits, something like
0000000000101010 (assuming 16-bit ints).

It's the same thing with pointers:

int *p = &x; /* see above for the declaration of x */

p is a pointer object. &x is a pointer value (an address). int* is a
pointer type. int* is the type of the pointer object p, and of the
pointer value &x, and &x is the current value of the pointer object p.
Note that, unlike with integers, we don't have a literal notation for
pointer values, other than the special case of a null pointer
constant; I use the expression &x as a stand-in for that particular
value. (If you print the value using printf's "%p" format, you might
get something like "0x12345678", or "1234:5678", or "a suffusion of
yellow"; the latter is highly unlikely but not forbidden by the
standard. This is a printed representation of the pointer value; it
is not the pointer value itself.) If the value we're referring to as
``&x'' is stored somewhere, it will be represented as a sequence of
bits; the way it's represented is entirely system-specific. The
standard imposes some requirements on how integers are represented;
there are no such requirements for pointers.

And like any other value in C, a pointer value has a type as well as
just a raw value. The value that results from evaluating the
expression ``42'' has type int, and thus is distinct from the value
that results from evaluating the expression ``42.0'', which has type
double. Similarly, the value of ``&x'' is of type int*; it's not
*just* a machine address, it's an address with a particular type. The
value of ``(void*)&x'', though it refers to the same machine address,
has a different type. The type information isn't stored in memory
during program execution, it's tracked by the compiler during
compilation.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 25 '08 #62
soscpd wrote:
Hello James, Bartc, List

On Sep 25, 8:45 am, James Kuyper <jameskuy...@verizon.netwrote:
A pointer value is the memory location itself.

My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?
A pointer object is a piece of memory that contains the address. The
pointer value is the location identified by that address. The term
"the pointer" could refer to either the pointer object or the pointer
value, but neither one is actually the address.
That, in my words, make the pointer to not be ever a value.
I don't understand why you would say that. The value of an object is,
always, an abstract thing, like the number 3.

The pointer value or object will never be 3 (sorry about "will not be
ever a value". What I mean is - the pointer value will never be 3, in
that case).
I was talking about "an object" in general, not specifically a pointer
object. I then moved to the example of an object with a value of '3',
which would necessarily be an object of numeric type, using it as an
analogy to show what the general relationship is between an object's
representation and an object's value. I guess I didn't make the fact
that I was making an analogy very clear.
... It will be the address of a memory location. The memory
location will have the desired value (well... that depends of what you
are looking for).
The value of a pointer object is the memory location of another
object. That other object can also have a value. I think you're
confusing the two values. If not, you're simply confusing me :-)
On Sep 25, 8:57�am, "Bartc" <b...@freeuk.comwrote:
....
Maybe the memory simply doesn't exist. Or is outside an allowed range.

Please, define allowed. You mean, allowed for defined behavior?
Well, yes, accessing such a pointer object's value has undefined
behavior, but that's not what he's referring to. Some bit patterns
represent valid locations, others do not. It's possible to create a
pointer object containing such an invalid bit pattern (an
uninitialized pointer object, a pointer object used to point at an
object whose lifetime has since ended, a FILE* object that used to
identify a stream that has since been fclose()d, type punning, etc.).
In all cases, such code is described by the standard as creating an
object with an indeterminate value. Such code has undefined behavior
if any attempt is made to use the value of such a pointer object.
the value might be valid for one type of target but not for another

Agreed. But that is not part of the (pointer) subject, IMHO.
Why we need to mix the pointer with the memory contents the pointer
point's to? There are too many possible values. Maybe understanding
pointers just as the address to memory locations will make our lifes
easy.
We don't need to mix them, we need to separate them and connect them.
Without clearly distinguishing between the representation and the
value of a pointer, and the representation and value of the thing it
points at, you can't make anyone's life easier, you're just going to
create confusion.
Through pointers, we can:
Reserve/Release some reserved memory(malloc & cia);
It's the function call that reserves or releases it; the pointer just
identifies where the location that has been reserved is.
Sep 25 '08 #63
ja*********@verizon.net writes:
soscpd wrote:
>Hello James, Bartc, List

On Sep 25, 8:45 am, James Kuyper <jameskuy...@verizon.netwrote:
A pointer value is the memory location itself.

My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?

A pointer object is a piece of memory that contains the address. The
Are you sure?

Is a piece of memory always allocated for a local pointer? In the rare
and wonderful systems I have used they are sometimes these wacky things
called registers and no memory is used.
Sep 25 '08 #64


Richard wrote:
ja*********@verizon.net writes:
soscpd wrote:
Hello James, Bartc, List

On Sep 25, 8:45 am, James Kuyper <jameskuy...@verizon.netwrote:
A pointer value is the memory location itself.

My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?
A pointer object is a piece of memory that contains the address. The

Are you sure?

Is a piece of memory always allocated for a local pointer? In the rare
and wonderful systems I have used they are sometimes these wacky things
called registers and no memory is used.
If you write code that could tell (for instance, code that used &p in
a non-trivial way) the compiler is required to make the code behave as
if a piece of memory was actually set aside for it; otherwise, the as-
if rule applies.

It's reasonable to discuss the as-if rule, and to point out particular
examples of how it can be applied. However, when discussing the
internals of C, it's a pointless task to try to describe everything in
a way that covers all of the possibilities opened up by the as-if
rule. Such a description would necessarily be either too vague or too
complicated to be useful.
Sep 25 '08 #65
ja*********@verizon.net writes:
Richard wrote:
>ja*********@verizon.net writes:
soscpd wrote:
Hello James, Bartc, List

On Sep 25, 8:45 am, James Kuyper <jameskuy...@verizon.netwrote:
A pointer value is the memory location itself.

My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?

A pointer object is a piece of memory that contains the address. The

Are you sure?

Is a piece of memory always allocated for a local pointer? In the rare
and wonderful systems I have used they are sometimes these wacky things
called registers and no memory is used.

If you write code that could tell (for instance, code that used &p in
a non-trivial way) the compiler is required to make the code behave as
if a piece of memory was actually set aside for it; otherwise, the as-
if rule applies.
Thats a lot of wind for "the compiler hides the real implementation".
>
It's reasonable to discuss the as-if rule, and to point out particular
Yes it is. In the same its "reasonable" to say a pointer is a numeric
address of an object in memory.

However, thats not what you did. You said "A pointer IS a piece of
memory". It is not necessarily.
examples of how it can be applied. However, when discussing the
internals of C, it's a pointless task to try to describe everything in
a way that covers all of the possibilities opened up by the as-if
Yes I agree. And so was somewhat surprised when I got hijacked when I
said a debugger was good to demonstrate pointers "pointing to memory"
since one can display the pointer *VALUE* and dereference the pointed to
memory in the debugger. It all starts to get a bit petty dont you think?
rule. Such a description would necessarily be either too vague or too
complicated to be useful.
Err, yes. I think....
Sep 25 '08 #66
ja*********@verizon.net writes:
soscpd wrote:
>Hello James, Bartc, List

On Sep 25, 8:45 am, James Kuyper <jameskuy...@verizon.netwrote:
A pointer value is the memory location itself.

My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?

A pointer object is a piece of memory that contains the address. The
pointer value is the location identified by that address. The term
"the pointer" could refer to either the pointer object or the pointer
value, but neither one is actually the address.
Not quite. The way the standard uses the word "address", a pointer
value *is* an address (at least if it actually points to an object or
function).

[snip]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 25 '08 #67
Richard<rg****@gmail.comwrites:
ja*********@verizon.net writes:
>Richard wrote:
>>ja*********@verizon.net writes:

soscpd wrote:
Hello James, Bartc, List

On Sep 25, 8:45 am, James Kuyper <jameskuy...@verizon.netwrote:
A pointer value is the memory location itself.

My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?

A pointer object is a piece of memory that contains the address. The

Are you sure?

Is a piece of memory always allocated for a local pointer? In the rare
and wonderful systems I have used they are sometimes these wacky things
called registers and no memory is used.

If you write code that could tell (for instance, code that used &p in
a non-trivial way) the compiler is required to make the code behave as
if a piece of memory was actually set aside for it; otherwise, the as-
if rule applies.

Thats a lot of wind for "the compiler hides the real implementation".
>>
It's reasonable to discuss the as-if rule, and to point out particular

Yes it is. In the same its "reasonable" to say a pointer is a numeric
address of an object in memory.

However, thats not what you did. You said "A pointer IS a piece of
memory". It is not necessarily.
No, he said that a pointer *object* is a piece of memory. The phrase
"a pointer" could mean either a pointer object or a pointer value,
i.e., an address.

And you're right, a pointer object isn't necessarily stored in
memory. The standard's definition of "object" is a "region of data
storage in the execution environment, the contents of which can
represent values". The phrase "region of data storage" can refer
either to memory or to one or more registers.

For that matter, the standard doesn't define the word "memory". One
*could* argue that a register is a kind of "memory", but the standard
does *use* the word memory in a way that makes it clear that registers
and memory are two different things. (Though there are CPUs on which
the registers are, or at least can be addressed as if they were, part
of main memory.)

Revised statement: A pointer object is a region of data storage that
can contain an address. (I changed "piece of memory" to "region of
data storage", and "contains" to "can contain", since a pointer object
needn't actually contain the address of anything.)

So congratulations. You have successfully picked a nit.
>examples of how it can be applied. However, when discussing the
internals of C, it's a pointless task to try to describe everything in
a way that covers all of the possibilities opened up by the as-if

Yes I agree. And so was somewhat surprised when I got hijacked when I
said a debugger was good to demonstrate pointers "pointing to memory"
since one can display the pointer *VALUE* and dereference the pointed to
memory in the debugger. It all starts to get a bit petty dont you think?
You were not "hijacked". People disagreed with you.

[...]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 25 '08 #68
Richard wrote:
ja*********@verizon.net writes:
....
If you write code that could tell (for instance, code that used &p in
a non-trivial way) the compiler is required to make the code behave as
if a piece of memory was actually set aside for it; otherwise, the as-
if rule applies.

Thats a lot of wind for "the compiler hides the real implementation".
....
However, thats not what you did. You said "A pointer IS a piece of
memory". It is not necessarily.
I said that a pointer object IS a piece of memory; this follows from
the C standard's definition of the word "object". It is necessarily
true, modulo the "as if' rule. More precisely, the as-if rule allows
an implementation to use something which is NOT a pointer object, by
reason of not residing in memory, to achieve the same results as if a
pointer object had existed. However, if a pointer object is used to
achieve that result, it must by definition occupy a "region of data
storage in the execution environment ...".

....
examples of how it can be applied. However, when discussing the
internals of C, it's a pointless task to try to describe everything in
a way that covers all of the possibilities opened up by the as-if

Yes I agree. And so was somewhat surprised when I got hijacked when I
said a debugger was good to demonstrate pointers "pointing to memory"
since one can display the pointer *VALUE* and dereference the pointed to
memory in the debugger. It all starts to get a bit petty dont you think?
There's a difference; the C standard describes the behavior of C
programs in terms of objects: how they are created, used, and
destroyed. An implementation can take C code that specifies the
creation of an object, and translate it in a way that doesn't actually
involve creating that object, but it can do so only by invoking the as-
if rule. It's therefore meaningful and useful to talk about the
objects in a C program, even if a particular object isn't actually
implemented as an object by a particular compiler.

Keep in mind that the number which is displayed by the debugger is not
the pointer's value, it is the pointer's representation, interpreted
as if it represented a number rather than a memory location. The
pointer's value is a memory location, not a number. While there is a
connection between that number and that memory location, it need not
be the simple kind of connection you believe to be nearly universal.

The C standard does not describe how a pointer object represents a
pointer value, and it says almost nothing about the number that can be
obtained by converting a pointer value into a number. Therefore, an
implementation is free to handle those things in any way that is
convenient to it, without needing to invoke the as-if rule. As a
result, there's little that can be meaningfully or usefully said about
such numbers, as far as C is concerned. Anything you say about those
numbers is implementation-specific, and therefore of negligible
interest to anyone using an implementation for which it isn't true.
It's also equally uninteresting to those of us who might even be using
exactly the same implementation as you, but who go out of our way to
write code in such a way that those details don't matter.
Sep 25 '08 #69
Richard Bos wrote:
ja*********@verizon.net wrote:
>soscpd wrote:
>>On Sep 25, 8:45 am, James Kuyper <jameskuy...@verizon.netwrote:
A pointer value is the memory location itself.
My question is - isn't the pointer the memory address? Just the memory
address, with nothing else?
A pointer object is a piece of memory that contains the address.

No. A pointer object is a piece of memory that contains the pointer.
This must, of necessity, contain an address, but it may contain other
information as well.
I didn't say anything to suggest that it couldn't contain additional
information.

....
>The pointer value is the location identified by that address.

_And_ all the other information.
I was using "address" is a more abstract sense than you are: I meant, by
"address", all of the information needed to identify the location. A
pointer can also contain other information which isn't needed to
identify the location.
>>Why we need to mix the pointer with the memory contents the pointer
point's to? There are too many possible values. Maybe understanding
pointers just as the address to memory locations will make our lifes
easy.
We don't need to mix them, we need to separate them and connect them.
Without clearly distinguishing between the representation and the
value of a pointer, and the representation and value of the thing it
points at, you can't make anyone's life easier, you're just going to
create confusion.

And the best idea is to ignore the representation while you're still
learning about pointers, and just get on with understanding their
purpose and use.
You don't need to know what the representation is; even for a
long-experienced professional, the issue is seldom important. I happen
to know from experience that, on the machine I use most often, pointers
are 4 bytes long, null pointer values happen to be represented by 0, and
non-null pointer values usually start with 0xffffff.... I don't know or
care why that is the case, and I can't think of any use I've ever made
of any of those facts except the size; and I know nothing else about how
pointers are represented on that machine - because I don't need to know.

However, any C programmer does need to understand, from a fairly early
point in the learning process, the concept that C objects (including
pointer objects) are pieces of memory that contain the representation of
a value. Without a proper understanding of the key distinction between
representation and value, much of C remains opaque and mysterious.
Sep 26 '08 #70
I am sorry,
I didn't even know what I was talking about.
The truth is, I don't even know how to program.
I regret all that I have said to you guys,
it seems I have just got problems.
I'm hoping this message will make up for all the
bad things I have said,
and all the things I said I knew, when I did not
understand any of it at all.
I know now that you guys were all right,
and I was wrong, and it is where I made
a big mistake.
I am sorry...
Oct 1 '08 #71
I am sorry, I didn't even know what I was talking about.
The truth is, I don't even know how to program.
I regret all I have said to you guys,
it seems I just have got problems.
I'm hoping this message will make up for
all the bad things I said,
and all the things I said I knew,
when I did not understand any of it at
all.
I know now that you guys were all right,
and I was wrong,
and it is where I made a big mistake.
I am sorry...
Oct 1 '08 #72
I am sorry,
I didn't even know what I was talking about.
The truth is, I don't even know how to progran.
I regret all I have said to you guys,
it seem I just have got problems.
I'm hoping this message will make up for all
the bad things I said,
and all the things I said I knew, when I did not
understand any of it at all.
I know now that you guys were all right,
and I was wrong,
and it is where I made a big mistake.
I am sorry...
Oct 1 '08 #73
Amkcoder said:
I am sorry,
I didn't even know what I was talking about.
To be more precise, you didn't know *enough* about what you were talking
about to justify the way in which you were talking about it. It is quite
clear that you have taken some trouble to learn your subject - it's just
that there's a lot you haven't learned yet. And one thing you hadn't
learned (but are perhaps in the process of learning?) is that there are a
lot of people in this group who know a great deal more about C than you
do, people from whom you can learn a lot.
The truth is, I don't even know how to program.
It isn't a Boolean skill - can or can't. You clearly *do* know a fair bit
about programming, but for *every* programmer there is always more to
learn.
I regret all that I have said to you guys,
Genuine apologies (which this appears to be) work well in comp.lang.c - no
matter how much you tick clc-ers off, most of them will be willing to let
bygones be bygones if you decide to make amends. Much of the intransigence
you see in clc is caused by people who are currently in the position that
you were in until recently, but either can't or won't understand that they
are in that position.

I would recommend that you draw a line under this episode, and continue to
use comp.lang.c as a learning resource. It is evident, from the very fact
that you posted tutorials in the first place, that you would like to help
others to learn, and that is a very worthy goal. In comp.lang.c, you can
learn a great deal about C that you can then pass on to others, as was
your original intention. If you choose to do that, everybody wins.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Oct 1 '08 #74
Amkcoder wrote:
I am sorry,
I didn't even know what I was talking about.
The truth is, I don't even know how to progran.
Or how to post on Usenet....

--
Ian Collins.
Oct 1 '08 #75
On 1 Oct, 17:25, Amkcoder <frontal_lobe_destro...@yahoo.comwrote:
I am sorry,
I didn't even know what I was talking about.
The truth is, I don't even know how to program.
I regret all that I have said to you guys,
it seems I have just got problems.
I'm hoping this message will make up for all the
bad things I have said,
and all the things I said I knew, when I did not
understand any of it at all.
I know now that you guys were all right,
and I was wrong, and it is where I made
a big mistake.
I am sorry...
and please fix your posting software!
Everything you post seems to arrive three times

--
Nick Keighley
Oct 2 '08 #76

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

12
by: Arlie Rahn | last post by:
I would like to ad a custom scroll bar control to my app that has a customizable and "flat" look to it (not the normal VB look). Does anyone have any ideas on where to find a good one?
8
by: sikka noel | last post by:
Hi guyz, I rencenly finished by college book on c++. I have done data structures & operating systems as well. I thought that at this point i know C++ completely. However when I go on internet...
2
by: mr_burns | last post by:
hi there, i would like a book that will explain concepts of javascript and dhtml instead of, for example, ten tutorials on how to do specific things in js or dhtml. ideally a book thats can...
9
by: Dragon | last post by:
Hi, I have 'some' experience in VB. I would like to learn C-Sharp and would like to know if the following book is any good or not. Thank you. Microsoft Visual C# .NET Step by Step - Version...
59
by: Alan Silver | last post by:
Hello, This is NOT a troll, it's a genuine question. Please read right through to see why. I have been using Vusual Basic and Classic ASP for some years, and have now started looking at...
5
by: spookyu | last post by:
Alright, I'm sure your tired to hearing this but...does anyone know of any GOOD tutorial's for learning c#. The more basic the better, I have NO experience with programing before this other than...
6
by: Jamiil | last post by:
I am not a programmer by any means, but a dedicated aficionado. I have good understanding of Java and C/C++, and now I would like to learn javascript->ajax, but I don't know where to start. My HTML...
8
by: At_sea_with_C | last post by:
Hello, I'm considering reading some C tutorials. I found this one. http://www.crasseux.com/books/ctutorial/ (The GNU C Programming Tutorial) Can anyone tell me if it is good or not? Also do...
4
by: David Williams | last post by:
WC3 Schools has a really good AJAX Tutorial http://www.w3schools.com/ajax/default.asp -- David Williams
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.