473,842 Members | 1,919 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

"Mastering C Pointers"....

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
Nov 13 '05
388 21968
Irrwahn Grausewitz <ir*******@free net.de> writes:
pete <pf*****@mindsp ring.com> wrote:
Mark McIntyre wrote:

And are functions objects?


No.
So can we settle on "a pointer is an object that can probably point to
another object, or possibly to a function, which is possibly not an
object, ouch my head hurts"?


A pointer doesn't have to be an object.
A pointer could also be the address of an object.


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.
--
"Large amounts of money tend to quench any scruples I might be having."
-- Stephan Wilms
Nov 13 '05 #231
Keith Thompson wrote:
Irrwahn Grausewitz <ir*******@free net.de> writes:
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.
Does this refer to Richard or to me?


No, I'm fairly sure it refers to Alan Connor. Irrwahn is right, you know -
it's a very... well, see for yourself.
If it's to me, be aware that the
UFO guy is a different Keith Thompson.


A likely story. ;-)

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #232
Richard Heathfield <do******@addre ss.co.uk.invali d> writes:
Keith Thompson wrote: [...] No, I'm fairly sure it refers to Alan Connor. Irrwahn is right, you know -
it's a very... well, see for yourself.


Oh, my.
If it's to me, be aware that the
UFO guy is a different Keith Thompson.


A likely story. ;-)


It's true. *beep* I come in peace. *beep*

--
Keith Thompson (The_Other_Keit h) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #233
On Wed, 05 Nov 2003 01:46:39 +0000, Richard Heathfield wrote:
Irrwahn Grausewitz wrote:
pete <pf*****@mindsp ring.com> wrote:
Mark McIntyre wrote:
>
> And are functions objects?

No.

> So can we settle on "a pointer is an object that can probably point to
> another object, or possibly to a function, which is possibly not an
> object, ouch my head hurts"?

A pointer doesn't have to be an object.
A pointer could also be the address of an object.


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. */


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.

------------------------------------------
Nov 13 '05 #234
"Alan Connor" <zz****@xxx.yyy > wrote in message
news:f%******** *********@newsr ead4.news.pas.e arthlink.net...
[snip] This is transparent character assassination. Do you think we are stupid?

At least on something we can agree. Assassination of character of clc
(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.
Nov 13 '05 #235
"Arthur J. O'Dwyer" <aj*@nospam.and rew.cmu.edu> wrote in message
news:Pi******** *************** ***********@uni x47.andrew.cmu. edu...

On Wed, 5 Nov 2003, pete wrote:

Mark McIntyre wrote:
Richard Heathfield <do******@addre ss.co.uk.invali d> wrote:
>Sheldon Simms wrote:
>>
>> Ok, let me try to tell you something about pointers that is
>> (hopefully) precisely correct, but won't confuse you.
>>
>> A pointer is a kind of variable that can "point to" some object.
>
>This isn't precisely correct. Sorry to dash your hopes.
>
>A pointer need not be variable. For example, there exists such a thing >as a null pointer constant.

And of course a null pointer is a pointer that doesn't point to
anythin.... So can we settle on "a pointer is an object that can probably point to
another object, or possibly to a function, which is possibly not an
object, ouch my head hurts"?


A pointer doesn't have to be an object.
A pointer could also be the address of an object.


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 "expression s 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.

Above "pairing" fails for "strings", which I believe can attribute for
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>).
Nov 13 '05 #236
On Wed, 05 Nov 2003 04:26:28 GMT, Keith Thompson <ks*@cts.com> wrote:


Richard Heathfield <do******@addre ss.co.uk.invali d> writes:
Keith Thompson wrote:

[...]
No, I'm fairly sure it refers to Alan Connor. Irrwahn is right, you know -
it's a very... well, see for yourself.


Oh, my.
> If it's to me, be aware that the
> UFO guy is a different Keith Thompson.


A likely story. ;-)


It's true. *beep* I come in peace. *beep*


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. :-)

--
Alan C this post ends with w
q
Nov 13 '05 #237
Sheldon Simms <sh**********@y ahoo.com> writes:
[...]
I suppose that depends on the definition of the word variable. Perhaps
this is why the C standard doesn't say much about "variables" .
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.
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.


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.

--
Keith Thompson (The_Other_Keit h) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #238
Keith Thompson wrote:
Sheldon Simms <sh**********@y ahoo.com> writes:

[...]
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.


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.


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.

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #239
August Derleth wrote:
Le*********@td. com (Lew Pitcher) wrote in message news:<3f******* ********@news21 .on.aibn.com>.. .
In college, I learned (to my later benefit) IBM 370 Assembly language.

Heh. I have an emulator for the System/360. It accepts batch jobs
(luckily, it doesn't take JCL) and returns a complete listing (a dump
if I've messed up).

Those old machines were rather interesting, especially where the
designers kind of knew what they really wanted but had to work around
the hardware to get something close.


Funny thing is, those "old" machines are still cranking out the data. In my
employed life (le*********@td .com) 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).
Around
the time I got my first real job in computers, I taught myself Intel 8080
Assembly /and/ Zilog Z80 Assembly language.

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.
Prior to that, I had a brush with
PDP-10 and PDP-11 assembler language, but never really understood them.

Then I guess you never learned the beauty that is VAX, I suppose?


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.
More's the pity: Understanding some of the intricacies of the DEC
minicomputers can help you grasp why some of C's crucial early design
decisions were made the way they were. For example, a flat memory
model and the whole notion of pre[increment|decre ment] being usefully
different from post[increment|decre ment] both came directly from the
PDPs.
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.

For what it's worth, I firmly believe that it would do most of the current crop
of "low level programmers" to learn IBM 370 Assembly language. This to find out
how to do things when you don't have a stack, aren't working in ASCII, and must
calculate with /very/ long decimal numbers. ;-)

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.

Nov 13 '05 #240

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

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.