"Mastering C Pointers"....

[maniac]

Hey guys, I'm new here, just a simple question.

I'm learning to Program in C, and I was recommended a book called,
"Mastering C Pointers", just asking if any of you have read it,
and if it's worth the $25USD.

I'm just looking for a book on Pointers, because from what I've
read it's one of the toughest topics to understand.

thanks in advanced.

sincerely ... Andy

 

[Sheldon Simms]

Hey guys, I'm new here, just a simple question.

I'm learning to Program in C, and I was recommended a book called,
"Mastering C Pointers", just asking if any of you have read it,
and if it's worth the $25USD.

I'm just looking for a book on Pointers, because from what I've
read it's one of the toughest topics to understand.

thanks in advanced.

Personally I find it hard to believe that anyone needs to
spend $25 on a book that only covers pointers, but that's just
me.

My suggestion would be for you to start out with a good general
purpose C book, like K&R, and then worry about other books only
when you actually have problems.

In fact, since you've already found this newsgroup, you can come
here with your problems (C problems, that is) first.

-Sheldon

Just before I hit send I decided I'd better search Amazon. I
found the following quote about this book:

"the writer uses turbo c and MS DOS;
it's kind of an old-school book"

That means you shouldn't use the book.

 

[Andy]

-Sheldon

Just before I hit send I decided I'd better search Amazon. I
found the following quote about this book:

"the writer uses turbo c and MS DOS;
it's kind of an old-school book"

That means you shouldn't use the book.

thanks, I just wanted some advice, thats all.
I appreciate your help.

 

[Roose]

Try "Pointers on C", that's not a bad book, and covers pointers fairly well.
It has a lot of basic C stuff too.

 

[Michael Str.]

Hey guys, I'm new here, just a simple question.

I'm learning to Program in C, and I was recommended a book called,
"Mastering C Pointers", just asking if any of you have read it,
and if it's worth the $25USD.

I'm just looking for a book on Pointers, because from what I've
read it's one of the toughest topics to understand.

thanks in advanced.

sincerely ... Andy

Hi Andy !

How many beer can you buy for $25USD ?

Try this link:
http://home.netcom.com/~tjensen/ptr/pointers.htm

I guess you can find many good links related to this issue.

regards
Michael

 

[Larry Niven]

I would rather read a book than reading on the Web, because I have poor eyesight.

Your eyes are more precious than $25USD, so I suggest you buy the book.

In fact, that book is worth reading.

 

[Sheldon Simms]

I would rather read a book than reading on the Web, because I have poor eyesight.
Your eyes are more precious than $25USD, so I suggest you buy the book.
In fact, that book is worth reading.

Apparently you have read the book. Tell me, do the words "far pointer"
and "near pointer" appear in the book? If so, don't read the book.

 

[Richard Heathfield]

Hey guys, I'm new here, just a simple question.

I'm learning to Program in C, and I was recommended a book called,
"Mastering C Pointers", just asking if any of you have read it,
and if it's worth the $25USD.

I am given to understand that the book is firmly rooted in MS-DOS, which
makes it unsuitable for /general/ understanding about pointers.

I'm just looking for a book on Pointers, because from what I've
read it's one of the toughest topics to understand.

Actually, pointers aren't really that hard to understand.

Every object is located somewhere, right? Well, when we refer to that
location, we "point" to the object.

In common parlance, the object's location is called an "address". An object
that stores an address is called a "pointer object". A value that is an
address is called a "pointer value". We can assign pointer values to
pointer objects.

There is a special pointer value called the null pointer value which is
guaranteed not to point to any object.

To "get at" the value stored at the address pointed to by a pointer, you
"dereference" the pointer. Thus:

int i = 6; /* i is an object with type int and the value 6 */
int j = 42; /* j is an object with type int and the value 42 */
int *p = &i; /* p is an object with type pointer-to-int and the value &i */

printf("i = %d\n", *p); /* deference p; prints 6 */
p = j; /* now p points at the j object */
printf("i = %d\n", *p); /* this time, it prints 42 */

It is also possible to point at functions. When you dereference a function
pointer, you actually call the function pointed to:

double (*fp)(double) = sin;

double d = (*fp)(180.0 / 3.14); /* d gets the value 0.0 */
fp = cos;
d = (*fp)(180.0 / 3.14); /* this time, d gets the value -1.0 */


When you do arithmetic with pointers, it is done in terms of the objects to
which they point. So if, say, you have an array of ints (and, as you may be
aware, ints normally are a tad bigger than a single byte):

int myarray[6] = { 0, 1, 2, 3, 4, 5 };

int *p = myarray; /* p points to first int in myarray array */
++p; /* p now points to /second/ int in myarray array, NOT the second byte
in the first int! */


One last point: it's not generally possible to know whether a pointer value
is valid or not unless its value is NULL, in which case you know for sure
that it's invalid. This is useful information.


That's it. Pointers are really that simple. If you're still having trouble
with pointers, ask a more specific question.

 

[Andy]

That's it. Pointers are really that simple. If you're still having trouble
with pointers, ask a more specific question.

well it sounds simple enough, but I've heard so many things about pointers
that I thought it will be a good idea to get a book just about pointers
but I guess C books have pointer references in them as well.

but I'll take your advice and ask here if I have more questions.

thanx.

 

[CBFalconer]

.... snip ...

One last point: it's not generally possible to know whether a
pointer value is valid or not unless its value is NULL, in which
case you know for sure that it's invalid. This is useful
information.

GNit: unless you know the pointers ancestry, i.e. how its value
was set. If it was never set you can be fairly sure it is
invalid.

 

[Richard Heathfield]

GNit: unless you know the pointers ancestry, i.e. how its value
was set. If it was never set you can be fairly sure it is
invalid.

Oh, absolutely right. And there are circumstances in which it can /become/
invalid even if you did set it. But I think the OP can cross those bridges
(with this newsgroup's help) when he comes to them.

 

[Richard Heathfield]

Actually, pointers aren't really that hard to understand.

printf("i = %d\n", *p); /* deference p; prints 6 */
p = j; /* now p points at the j object */

If pointers are so easy, why did I make this mistake? It should, of course,
be:

p = &j;

Thanks to "those who know me have no need of my name" for pointing this out.

 

[Alan Connor]

I am given to understand that the book is firmly rooted in MS-DOS, which
makes it unsuitable for /general/ understanding about pointers.


Actually, pointers aren't really that hard to understand.

Every object is located somewhere, right? Well, when we refer to that
location, we "point" to the object.

Richard,

Would you mind defining "object" for a shell scripter just starting to
learn C?

(I've saved this pointer article. Thanks.)

 

[Malcolm]

Would you mind defining "object" for a shell scripter just starting to
learn C?

The problem is that "object" has one meaning in object-oriented programming,
and a related but different menaing in C.

In C an "object" is something that a variable, either a basic type like an
int or a float, or a compound type like a structure, can hold. Because C
allows direct access to memory, an "object" is just an area of memory that
is interpreted in a certain way.

In object-oriented programming, an "object" is a data type that represents
something in the world the program is trying to simulate, and which has
relationships with other objects. For instance, you might have
"streetlights", "torches", "headlights" and "traffic lights" as light
objects in your program, and all might be related because all have an
intensity, a colour, and a location.

Underneath the bonnet, object-oriented "objects" are of course stored as
patterns of bits in memory, but many object-oriented languages don't allow
or discourage accessing this memory directly.

 

[Roose]

In C, there is no technical term "object", but he means anything which
occupies memory can be pointed at. Any code (a function, individual CPU
instructions) or data (a simple int, char; an array; a struct or union; a
block of malloc'd memory) can be pointed at.

I remember learning C, and being confused by the syntax of the language. If
they had just put it in terms of simple arithmetic (which is ALL it is,
really), then I would have been able to grasp it quicker. Unfortunately I
haven't seen a lot of books that do this, because it requires some basic
hardware knowledge (which is pretty trivial). Most books are biased toward
the abstract, since that is what standard C is -- an abstraction of
hardware. BUT it will help a lot to ALSO come at it from the concrete side,
i.e. see what is going on in the memory of your computer. To learn anything
you need to have more than one representation of it in your head; otherwise
you're just memorizing facts and words.

I would suggest learning to read hex (e.g. what decimal value is 0x00010000)
if you don't, and copy some C functions which use:

- pointers of different types (pointer to int, char; pointer to struct;
pointer to array, etc)
- the & operator
- the ++ -- += -= operators on pointers (as opposed to pn integers)
- the * operator

Compile and run them. Get a good debugger (Codewarrior, MSVC++ work fine),
and open up the stack window. Also helpful is a debugger which can view
memory as an array of hex numbers. View the stack as memory as well. See
how the variables are laid out consecutively on the stack. See that a
pointer is an integer at the hardware level. Step through _each line_ of
code and _very carefully_ note what happens to each variable. Take note of
how they are incremented/decremented. See how pointers to variables on the
stack have numeric values that are the addresses in your debugger's memory
viewer.

Then if the code uses the [] or -> operators, rewrite these in terms of the
previous operators, and then you will really understand what they do.
Change loops that use [] to use pointers.

This exercise will also help when you inevitably make some mistake with
pointers. If you only think about the abstract C language, then when you
start to program you will be utterly confused and frustrated when you
overrun a buffer and start reading garbage values, or when you cause a
machine exception by dereferencing a bad pointer. In shell scripting for
example, you don't really run into variables with garbage values, and it
will help to understand why.

When you understand this concrete stuff, the abstract will become clearer as
well. You'll understand why the C language was designed as it is. It seems
like a weird language at first, but you will see that it is a very thin
layer on of hardware.

 

[Irrwahn Grausewitz]

Would you mind defining "object" for a shell scripter just starting to
learn C?

Generally, in C an object is something that can hold a value.

The C Standard states:

ISO/IEC 9899:TC1
3.14 object
region of data storage in the execution environment, the contents of
which can represent values.
NOTE: When referenced, an object may be interpreted as having a
particular type; see 6.3.2.1.

6.3.2.1 Lvalues, arrays, and function designators
An lvalue is an expression with an object type or an incomplete type
other than void; [...] When an object is said to have a particular
type, the type is specified by the lvalue used to designate the object.
[...]

The C Rationale explains:
The definition of object does not employ the notion of type. Thus an
object has no type in and of itself. However, since an object may only
be designated by an lvalue (see 6.3.2.1), the phrase "the type of an
object" is taken to mean, here and in the Standard, "the type of the
lvalue designating this object", and "the value of an object" means
"the contents of the object interpreted as a value of the type of the
lvalue designating the object".

<phew> Confused?
Let's have a look at a simple example:

int i = 42;

With this definition we create an object of size sizeof(int) that
resides somewhere in memory. The only way to access this object is
via the 'name' we gave it: i. Since i has type int and we provided
an initial value of 42 we now can say:

i is an lvalue designating an object of type int that contains the
value 42.

or, less correct, but much more convenient:

i is an {object of type} int with value 42.


Another one:

char *cp = NULL;

cp is an lvalue designating an object of type pointer-to-character
that contains the value NULL.

or just:

cp is an {object of type} pointer-to-character with value NULL.


HTH a bit
Regards

 

[Richard Heathfield]

Richard,

Would you mind defining "object" for a shell scripter just starting to
learn C?

Sure. It's a region of storage.

Here are some trivial examples:

int i = 6; /* i is an object. It has type int, and the value 6 */

double d = 3.14; /* d is an object, of type double and value 3.14 */

struct foo { int n; double r; } myfoo = { 42, 1.618 }; /* myfoo is an object
of type struct foo, with a value that I choose to express as { 42, 1.618 }
*/

Less trivial examples exist, as I'm sure you really didn't want to know.

(I've saved this pointer article. Thanks.)

Please apply the correction, too.

In case you missed it, p = j; should be p = &j;

 

[Richard Heathfield]

In C, there is no technical term "object",

Wrong. The C99 standard defines "object" as "region of data storage in the
execution environment, the contents of which can represent values". The
earlier standard defines the same term in the same way.

It's hard - very hard - to read the language definition for any length of
time without coming across the term.

but he means anything which
occupies memory can be pointed at.

Wrong. That's not what I meant. I meant what I said.

Any code (a function, individual CPU
instructions) or data (a simple int, char; an array; a struct or union; a
block of malloc'd memory) can be pointed at.

No, there is no well-defined way, in C, to point at individual CPU
instructions. Furthermore, functions (which /can/ be pointed at) are not
objects.

<snip>

You offered some highly implementation-specific advice which may well
confuse rather than elucidate. I've removed it from this reply as a service
to the reader.

 

[Roose]

I know you still hold a grudge for being so thoroughly embarassed, but give
it a rest. You already know my position. I am concerned with the real
world. I am trying to help the guy out in a useful and simple way, and not
confuse him with irrelevant details. FIRST you learn how to write a program
that RUNS and does what you want, then you learn how to write portable C and
the C standard (if ever). Writing portable C takes considerably more time,
at least for the beginner.

Fine I was wrong about the term object. Having worked as a professional C
programmer for many years, I have never heard anyone refer to an "object" in
C in this technical sense. That tells you how useful this term is. Also
it's common for programmers to program in both C and C++, so using the term
object in C is confusing. It's not an important word at all in C, but very
important in C++.

You offered some highly implementation-specific advice which may well
confuse rather than elucidate. I've removed it from this reply as a service
to the reader.

I think your advice was fine, worth reading. But as I noted in my post, you
need to learn something from at least two perspectives to _really_ learn it.
Approaching it from the abstract only is not sufficient. You have to learn
_specifics_ and then generalize. As a person with some teaching experience
as a TA, I can say this for a fact. People, in general, are not good at
grasping generalizations and abstractions. They need to have something
concrete to feel out first.

Could you learn what a ring is without learning how to use integers and
matrices? Etc. It doesn't mean anything without specifics.

I'm trying to help the guy learn. You're trying to beat off to your
knowledge about the C standard.

(Also, if you mention the quoting again, I'm going to force you into
childish, desperate wordplay again...)

 

[Thomas Stegen]

Roose wrote:

[snip]

Can you just please stop being so defensive? There is nothing
wrong with being wrong. A simple thank you when you are being
corrected gives more credo than having to be dragged kicked and
screaming out of ignorance.

The grudge seems to be on your side FWIW.