473,889 Members | 1,352 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 21994
Alan Connor <zz****@xxx.yyy > writes:
[...]
After reading the first 1/3 carefully, it seems to me that a pointer is very
much like a symlink.


That's not a bad analogy. Like any analogy, it can be carried too far
if you're not careful, but it's a good start.

--
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 #141
In article <kg************ *************** *****@4ax.com>,
ma**********@sp amcop.net says...
Actually, I have a nasty suspicion that Roose is talking to himself,
although I could be quite wrong. Its just that . I noticed with
interest an exchange not dissimilar to this just now:

Roose said: something incorrect
Richard replied: no, thats wrong
Alan said: oh, thats what I meant.

Note the use of the personal pronoun in the last response.


I didn't notice that, but I will say that my "sockpuppet radar"
went off full blast reading throught this thread.
--
Randy Howard _o
2reply remove FOOBAR \<,
_______________ _______()/ ()_____________ _______________ _______________ ___
SCO Spam-magnet: po********@sco. com
Nov 13 '05 #142
> After reading the first 1/3 carefully, it seems to me that a pointer is
very
much like a symlink.
Uh, I'm not exactly sure what a symlink is, but if it is anything like a
Windows shortcut, there is definitely an analogy there.

The windows shortcut just stores the location of a file. A "pointer" to it.
An address. The address is the _path name_. In C, the "address" is
basically an integer, indicating where in a huge array of memory the
variable is.

You can have as many shortcuts as you want that point to the file. A
shortcut takes a small amount of storage, but not as much as a (typical)
file. You can have whole directories of shortcuts that point to files all
over the place, in order to organize them. Likewise, you can have
collections of pointers, that point to various different things _scattered_
all over memory.

For example, on my hard disk, I have a whole bunch of (legal) MP3s organized
by artist and by album. Now, some of them were ripped poorly and have
clicks. So I *could* just copy those files to another folder, in order to
note that I need to rip them again.

However, it is *much* easier and efficient to just copy shortcuts those bad
files into another folder -- called "bad". That way I don't duplicate any
data. And I have all the bad files organized in one directory, and can
access them easily.

You could do the exact same thing with pointers. Suppose I had a whole
bunch of strings in memory, that listed a ton of song names. I could create
an array of pointers called "theBeatles " that pointed to every single song
by the Beatles. Then I could have an array of pointers called "badFiles"
that pointed to all the bad files, _some of which_ may be by the Beatles.
Note that I haven't incurred the storage cost of repeating the strings,
*just* pointers to them. Likewise I could create another array called
"before1960 " that points to all songs stored before 1960 -- you get the
idea.

Hm, I'm surprised this didn't come up earlier. This is an easy analogy.

In your debt, Sheldon. Expect some more questions directly from this tutorial in the future.
--
Alan C this post ends with w
q

Nov 13 '05 #143
In article <bo**********@h ercules.btinter net.com>,
do******@addres s.co.uk.invalid says...
Alan Connor wrote:

<snip>
We'll see. But trolling gets anyone killfiled for a while. I don't care
if it's being done by Dennis Ritchie.


Ah, the irony! The exquisite irony!


*cackle*

--
Randy Howard _o
2reply remove FOOBAR \<,
_______________ _______()/ ()_____________ _______________ _______________ ___
SCO Spam-magnet: po********@sco. com
Nov 13 '05 #144
"Roose" <no****@nospam. nospam> writes:
For example, Roose said "a pointer is an integer". This is not
true. A pointer *might* be an integer, and it might be something
else, like two distinct integers, or something else entirely.


How about, "At least some bits of the binary representation of a
pointer can be interpreted as an integer." I didn't say anything
about casting pointers to integers.


I don't believe that's an improvement. In some implementations , the
underlying representation of a pointer is the same as that of an
integer. But if you want to understand pointers in general, and use
them in portable code, it's best not to worry about any equivalence
between pointers and integers.

To take it to a perhaps ridiculous extreme, if you think of a pointer
as being a finger that literally points to an object (I'm using term
"object" the way the C standard uses it), with certain operations you
can perform on it (move the finger N objects forward or backward, grab
what the finger points to, etc.), you won't go far wrong.

If you think of a pointer as just an integer, it will be difficult to
understand why, for example, you can add a pointer and an integer, but
you can't add two pointers.

As I've said elsethread, there's nothing wrong with understanding the
underlying representation, especially if you understand the variations
across differing implementations . But the idea that parts of a
pointer can be interpreted as an integer is actually one of the least
important things to understand about pointers.

[...]
I don't know why you are learning C, but lets imagine that you
might someday want to program professionally using C. If so, you
might find it professionally embarrassing when your code crashes
the airplane, cash register, medical device, file server, robot,
etc. because you assumed that a pointer is "just an integer",
as Roose urged you to.


This is a straw man. Any program, of critical nature or not, is tested, and
these types of errors don't even take testers to figure out. The code
simply won't work when you try it for the first time. If you want to make
an error-free program for one device, it is probably safer to find out the
specifics of your hardware, and program to that. Rather than coding in 100%
"standard ANSI C" and hoping the compiler does the right thing. If not,
then it will at least save you a lot of time.


Testing can only demonstrate the presence of bugs; it can't prove
their absence. There are plenty of bugs that only appear under
unusual circumstances. Pointer bugs can easily cause sporadic
failures that might be missed by testing. Imagine a bug that only
shows up when an airplane does a 10 degree left bank between 28,000
and 30,000 feet during a daylight saving time transition in a location
where true and magnetic north differ by 2 degrees. (That scenario is
purely a product of my imagination).

--
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 #145
> This is very sophisticated duelling, and somewhat entertaing, but I'd much
rather you were each expounding upon the fundamentals of C in your individual and unique styles.
Well, I can do both : )

But I am curious, Roose, as to why you continue feeding the troll? Trolls
don't care about reason or truth or the subject at hand. They pretend to be in order to create and win a game of dominance in which they can't increment the value of SELF but must decrement the value of OTHER.
Well, I was the one who stopped in the previous flamewar (see the thread
about how you tell if a struct is 0, if you haven't seen it), and that will
likely be the case here.

It's all in good fun. I enjoy a good argument. Richard is at least fun to
argue with, because he grasps basic ideas and arguments (unlike some already
noted, who fail to understand the basic line, and respond with lame insults,
and who I *don't* respond to). Unfortunately, when you corner him, he
resorts to children's games, or simply refuses to answer, and then I stop.
No more fun then.


--
Alan C this post ends with w
q

Nov 13 '05 #146
Mark McIntyre wrote:
On Mon, 03 Nov 2003 18:50:09 -0500, in comp.lang.c , Sheldon Simms
<sh**********@y ahoo.com> wrote:
On Mon, 03 Nov 2003 21:29:12 +0000, Alan Connor wrote:
Got really fed up with the Richard fellow. Killfiled his arrogant ass
for a while.


You are of course welcome to killfile anyone you want, however you
should be aware that Richard is telling you the truth and Roose is
not.


Actually, I have a nasty suspicion that Roose is talking to himself,
although I could be quite wrong. Its just that . I noticed with
interest an exchange not dissimilar to this just now:

Roose said: something incorrect
Richard replied: no, thats wrong
Alan said: oh, thats what I meant.

Note the use of the personal pronoun in the last response.


Well, I thought that too, at first, but I now think it is unlikely, as a
little traffic analysis will show.

Firstly, Alan Connor first posted to this newsgroup in early October of this
year, well before Roose, and he showed every sign of being a thoughtful and
positive subscriber. This is clearly not the case with Roose, he shows
every sign of being another Tisdale (albeit marginally less entertaining).

Secondly, by 17th October Mr Connor's sig block had been changed to read:
"Posts with sigs of > 4 lines, or not in plain text, are dumped by my
filters.", which suggests (or at least hints) that he takes netiquette
seriously, or at least wishes others to believe that he does. Having said
that, this does make his decision to champion Roose The Top-Poster rather a
strange one, but that's entirely up to him.

Finally, this may be as appropriate a place as any to attempt to pour oil on
troubled waters. During this thread I have been repeatedly characterised as
a troll by Roose and Mr Connor. I attribute this to their ignorance, which
can be cured by education. I don't bear either of them a grudge, and I'm
perfectly prepared to play nice.

As I am sure I have said before, comp.lang.c is a mirror, and what you get
is probably what you are. I have therefore been most heartened by the
contributions of most of the posters in this thread. Thanks to you all.

--
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 #147
On Tue, 4 Nov 2003 01:18:34 -0600, Randy Howard <ra**********@F OOmegapathdslBA R.net> wrote:


In article <%Q************ *******@newssvr 21.news.prodigy .com>,
no****@nospam.n ospam says...
Chris, I enjoyed reading your post and there is definitely interesting
information here. But I would contend that if someone doesn't yet have a
good understanding of pointers, he won't have the foggiest idea what you're
talking about. : )


Roose, if you want to be a moderator of a newsgroup, why do you not go
start one and see how many sheep wish to join your flock?


That's completely unfair. You could just as well paint Richard with the
same brush.

This is transparent character assassination. Do you think we are stupid?

--
Alan C this post ends with w
q
Nov 13 '05 #148

"Keith Thompson" <ks*@cts.com> wrote in message
news:lz******** ****@cts.com...
"Roose" <no****@nospam. nospam> writes:
For example, Roose said "a pointer is an integer". This is not
true. A pointer *might* be an integer, and it might be something
else, like two distinct integers, or something else entirely.
How about, "At least some bits of the binary representation of a
pointer can be interpreted as an integer." I didn't say anything
about casting pointers to integers.


I don't believe that's an improvement. In some implementations , the
underlying representation of a pointer is the same as that of an
integer. But if you want to understand pointers in general, and use
them in portable code, it's best not to worry about any equivalence
between pointers and integers.


OK, suppose you want to serialize a group of structs, which contain pointers
to each other (a graph). In game programming, for getting data into the
game, it's a common idiom to subtract the base address in the PC tools,
store it on disk, and rebind the pointers at runtime in the game engine by
adding back a new base address. You can't do that without understanding the
equivalence, since of course you only read ints from binary files at first.

Of course this is not portable, but it works on 3 game consoles, and I would
contend that there is way to the exact same thing on ANY platform (with the
bit masking/arithmetic being slightly different, etc.)
To take it to a perhaps ridiculous extreme, if you think of a pointer
as being a finger that literally points to an object (I'm using term
"object" the way the C standard uses it), with certain operations you
can perform on it (move the finger N objects forward or backward, grab
what the finger points to, etc.), you won't go far wrong.

If you think of a pointer as just an integer, it will be difficult to
understand why, for example, you can add a pointer and an integer, but
you can't add two pointers.
Well, if you understand _what_ a pointer-as-an-int means, I think you would
understand already why it doesn't really mean much to add two pointers.
Testing can only demonstrate the presence of bugs; it can't prove
their absence. There are plenty of bugs that only appear under
unusual circumstances. Pointer bugs can easily cause sporadic
failures that might be missed by testing. Imagine a bug that only
shows up when an airplane does a 10 degree left bank between 28,000
and 30,000 feet during a daylight saving time transition in a location
where true and magnetic north differ by 2 degrees. (That scenario is
purely a product of my imagination).


Can you explain how an error in not writing standard C might result in such
a bug?

Roose
Nov 13 '05 #149
Alan Connor wrote:
That's completely unfair. You could just as well paint Richard with the
same brush.
But I am not seeking to change the existing behaviour of the newsgroup.
This is transparent character assassination. Do you think we are stupid?


No, but I do think you're misguided.
--
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 #150

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.