Help with pointers

[Peter Mount]

Hello

Are there any good online tutorials that explain pointers in ANSI C? I've
covered pointers in my course but I'm just having trouble "getting it to
sink in".

Thanks

Peter Mount
(e-mail address removed)

 

[Mike Wahler]

Hello

Are there any good online tutorials that explain pointers in ANSI C? I've
covered pointers in my course but I'm just having trouble "getting it to
sink in".

http://pw1.netcom.com/~tjensen/ptr/pointers.htm

http://67.40.109.61/torek/c/pa.html

-Mike

 

[Kevin Zhou]

Hello

Are there any good online tutorials that explain pointers in ANSI C? I've
covered pointers in my course but I'm just having trouble "getting it to
sink in".

Thanks

Peter Mount
(e-mail address removed)

http://pweb.netcom.com/~tjensen/ptr/pointers.htm

this might help

 

[Darrell Grainger]

Hello

Are there any good online tutorials that explain pointers in ANSI C? I've
covered pointers in my course but I'm just having trouble "getting it to
sink in".

Google is your friend. Go to www.google.ca/grphp and enter:

group:comp.lang.c pointer tutorial

Search the results and you should find some good tutorials.

 

[Kamilche]

Hello

Are there any good online tutorials that explain pointers in ANSI C? I've
covered pointers in my course but I'm just having trouble "getting it to
sink in".

http://www.kamilche.com/c/ - click on the 'Essays' tab, there are 2
explanations of pointers I've written to help myself and others
understand pointers. I wrote them just after I 'got' pointers, while
all the confusion was still fresh in my mind... so it should be
especially useful to newbies.

 

[Mabden]

"Peter Mount" <[email protected]> wrote in message

Learning Assembler helps. Once you deal with the low-level machine
instructions, you get a good sense of how a variable can point to another
chunk of memory. Since everything you do is so close to what the CPU itself
is doing, you learn "how a computer works".

====================================================================
(The following is encased in flame-proof story-telling mode. I don't want to
debate the finer points of my coding skills. The following may not even be
compilable code. That Is Not The Point. Really, if you have something
negative to say, just write it out on toilet paper and flush it. Thank you
for your support.)


To go Zen on you:


Pointers are arrows. By themselves they point to nothing, you must "fire
them" at a location at which time you can refer to them.


int tree=10; // A Real Thing: actual memory is allocated and set to value
10
int *arrow; // Not a Real Thing, points anywhere / nowhere
int clone; // a Real Thing, no value set


arrow = tree; // zing: arrow points to tree,
// you can use either tree or *arrow to use or change the
value of tree.

clone = arrow; // no good! arrow is a pointer to a tree not a tree itself.
// You can't take an arrow and pretend it's a tree - it does
have leaves and grow!

clone = *arrow; // clone now equals 10, because we took the value in tree
and copied it to clone.
// We got the value of tree by grabbing the arrow that
points to tree and "tugging" on it.

tree = 20; // tree is now different than clone, but *arrow (which is stuck
in tree) is now 20 also.

arrow = clone; // You just pulled the arrow out of tree and stuck it in
clone. *arrow is now 10 again.

tree = 30; // tree changes, arrow doesn't change as it's over in clone.
clone doesn't change.

clone = 25; // *arrow changes to 25, since it's stuck in clone now.
====================================================================

 

[Chris Torek]

(The following is encased in flame-proof story-telling mode. I don't want to
debate the finer points of my coding skills. The following may not even be
compilable code. That Is Not The Point. Really, if you have something
negative to say, just write it out on toilet paper and flush it. Thank you
for your support.)

If our code need not even compile, much less run, we might as well
all go home.

To go Zen on you:

Pointers are arrows. By themselves they point to nothing, you must "fire
them" at a location at which time you can refer to them.

This much is OK...

int tree=10; // A Real Thing: actual memory is allocated and set to value
10

This shows the problem with C99's "//"-comments, at least
in newsgroups. The comment ends at "set to value", and
then there is another line that reads "10".

int *arrow; // Not a Real Thing, points anywhere / nowhere

This is a bit of a problem, because while pointers do need to be
set to point to somewhere, they are also "real things" in themselves.
Thinking of pointers as "fake" will lead to problems with pointers
pointing to pointers. It might perhaps be better to think of these
as "end of journey" vs "not yet end of journey" things.

I will leave the rest of this alone (bugs and all). Just remember
that analogies are always flawed. C pointers are what the C standard
says they are. They may or may not be somewhat like something
else, but the appropriate standard is the final arbiter. (Or, if
you are writing system-specific code that merely happens to use C
as the source expression language, your compiler and/or machine is
the "really final" arbiter, but if you want your code to work
everywhere -- rather than only on one specific compiler on one
specific machine -- you should not depend on extra stuff specific
to that implementation.)

 

[Ed Morton]

Mabden wrote:

int tree=10; // A Real Thing: actual memory is allocated and set to value
10
int *arrow; // Not a Real Thing, points anywhere / nowhere
int clone; // a Real Thing, no value set


arrow = tree; // zing: arrow points to tree,

arrow = &tree;

arrow = clone; // You just pulled the arrow out of tree and stuck it in

arrow=&clone;

 

[Joona I Palaste]

This much is OK...

This is a bit of a problem, because while pointers do need to be
set to point to somewhere, they are also "real things" in themselves.
Thinking of pointers as "fake" will lead to problems with pointers
pointing to pointers. It might perhaps be better to think of these
as "end of journey" vs "not yet end of journey" things.

Pointer variables hold values of type "pointer to some type", where
"some type" is any C type that a variable can hold values of.
Pointer *values* can be thought of "not real things" but the variables
that hold these values certainly can't, because as Chris correctly
notes, they're very much "real things".
Consider 1. As far as C goes, where it takes up space - if it takes up
space in the first place - is not defined, it's simply an integer value
that has the value 1. Now write the following C code:
int i;
i=1;
As far as C goes, i is a very "real thing" - it takes up sizeof(int)
bytes of space and has a specific location in automatic storage.
Now we come to the point of our analogy. Consider &i. As far as C goes,
it's the same as 1 in our previous example. Now write the following C
code:
int *p;
p=&i;
As far as C goes, p is very much similar to i. It takes up
sizeof(int *) bytes and has a specific location in automatic storage.

Have I gone all Zen on you, or have you actually understood something?

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge

 

[Eric Sosman]

[concerning how to learn about pointers:]
Learning Assembler helps. Once you deal with the low-level machine
instructions, you get a good sense of how a variable can point to another
chunk of memory. Since everything you do is so close to what the CPU itself
is doing, you learn "how a computer works".

IMHO, learning an assembly language is a poor way to learn
about pointers, because you learn a lot of things that are true
of addresses but do not apply to pointers. For example, you learn
the oft-rediscovered hack of double-linking a list by storing the
XOR of the addresses of the adjacent nodes; try that in C and
you'll soon discover that you need to un-learn a few things ...

Learning "how a computer works" can be a good thing, but it's
not a substitute -- or even a prerequisite -- for learning how the
language works. When I started out, "how the computer works" was
about little magnetic doughnuts with tiny wires threaded through
them; I opine that this knowledge had no relevance to understanding
how to construct a loop. Array indexing was done by performing
arithmetic on instructions in memory and then executing the modified
instructions; this notion of "how a computer works" would be, I
think, positively harmful in understanding arrays in C.

I have known plenty of skilled programmers, some of whom treated
their programming languages -- FORTRAN, PL/I, C, you name it -- as
sugar-coating for an assembler. Some of these folks wrote programs
that were downright astonishing, but I cannot recall any of these
confections surviving a change of machine -- some wouldn't even
survive a compiler upgrade. In those days *some* shenanigans of
this kind could be justified on the grounds of efficiency: If a
program *had* to fit in one disk sector or be un-runnable, there
wasn't too much choice. But the economies that drove such choices
reversed themselves long ago: programmer effort (and testing effort,
and support effort, and ...) have become far more costly than the
once-precious Computer Minute.

Do not write assembly in C; write C in C.

 

[Neil Cerutti]

Pointer variables hold values of type "pointer to some type",
where "some type" is any C type that a variable can hold values
of. Pointer *values* can be thought of "not real things" but
the variables that hold these values certainly can't, because
as Chris correctly notes, they're very much "real things".
Consider 1. As far as C goes, where it takes up space - if it
takes up space in the first place - is not defined, it's simply
an integer value that has the value 1. Now write the following
C code:
int i;
i=1;
As far as C goes, i is a very "real thing" - it takes up
sizeof(int) bytes of space and has a specific location in
automatic storage. Now we come to the point of our analogy.
Consider &i. As far as C goes, it's the same as 1 in our
previous example. Now write the following C code:
int *p;
p=&i;
As far as C goes, p is very much similar to i. It takes up
sizeof(int *) bytes and has a specific location in automatic
storage.

Have I gone all Zen on you, or have you actually understood
something?

We can invoke the "little computer people" if another metaphor is
needed. I find those little buggers so cute, and they can do
anything. ;-)

 

[Mabden]

<comment chars changed for wrapping>

Mabden wrote:

arrow = &tree;
*/
arrow=&clone;

Oops, I guess the OP isn't the only one who needs help with pointers! ;-)

Of course I agree with those who wrote in saying pointers are real things,
since they still occupy a memory location. But then in the analogy, an arrow
is also a Real Thing, since you can fire it into a tree or scratch your back
with it. The point (so to speak) was that it can by set to point at
something bigger (the tree being an object, structure, or something much
bigger than the arrow) and then plucked free to point at something
completely different, like a straw target or a tasty deer. Or just put back
in the quiver to point at nothing again.

I guess a pointer to a pointer would be called a Robin Hood?