473,889 Members | 1,358 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 > wrote:
On Mon, 03 Nov 2003 22:33:15 +0100, Irrwahn Grausewitz <ir*******@free net.de> wrote:

Alan Connor <zz****@xxx.yyy > wrote:
I didn't need those cavils, and he was addressing me.
But he posted to the news-group. There is not much privacy in
usenet discussions, ya know?!?


He was very helpful. More helpful than crap like this by far.

I'm interested in learning C,


The only thing you can learn from Roose is how to troll a news-group.
not playing a role in your stupid-assed
soap opera.


It's not a soap opera. It's reality. Wake up.
--
Irrwahn
(ir*******@free net.de)
Nov 13 '05 #111
Alan Connor <zz****@xxx.yyy > wrote:
On Mon, 03 Nov 2003 18:50:09 -0500, 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. At least, he is not telling you the whole truth.


And all the people that ARE, are doing nothing but confuse me.


Oh, poor boy. Didn't the evil guys in usenet act as you wanted them
to? Too bad. Yes, life can be sooooo hard.

If you are not interested in correct information you can get from
the other posters here, take this Roose troll with you and move over
to alt.comp.lang.c . Virtually nobody else is posting there, so maybe
it's a good place for you two to stay.

Irrwahn
--
No man is an island -- but some of us are long peninsulas.
Nov 13 '05 #112
Chris Torek wrote:
....snip ...
For something really different, I would suggest trying these:

- Univac 11xx series: 18 and 36 bit integers, ones' complement
arithmetic. C compilers use 9-bit bytes.

- Data General Eclipse: conventional flat-memory RISC with one
twist: "byte pointers" (for char * and void *) are different
from all other, normal "word pointers". To convert a word
pointer to a byte pointer, the compiler must shift it left,
introducing a low-order zero bit.

- IBM AS/400. This is a "virtual architecture" with segmented,
protected memory. Pointers carry special qualification values
(a sort of access control list, as it were, or a "capability "
as it is usually called in other systems); pointers to code
are *much* larger than pointers to data.

One last architecture, for which I doubt there are any C compilers
(or even machines left? :-) ), that can expand one's idea of how
to build computers, is the Burroughs A-series. There is a brief
(albeit a bit "gushy" :-) ) overview at
<http://www.ajwm.net/amayer/papers/B5000.html>. (Many might quibble
with the claim that the Burroughs was the first machine to have
virtual memory, giving that honor instead to Manchester's Ferranti
Atlas.)


Shouldn't the HP3000 running MPE fit in there somewhere? I
believe it just became unsupported. Many Burroughsisms. It DID
have a C compiler 25 years ago.
--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!
Nov 13 '05 #113
Chris Torek <no****@elf.eng .bsdi.com> writes:
[...]
For something really different, I would suggest trying these:

- Univac 11xx series: 18 and 36 bit integers, ones' complement
arithmetic. C compilers use 9-bit bytes.

- Data General Eclipse: conventional flat-memory RISC with one
twist: "byte pointers" (for char * and void *) are different
from all other, normal "word pointers". To convert a word
pointer to a byte pointer, the compiler must shift it left,
introducing a low-order zero bit.

- IBM AS/400. This is a "virtual architecture" with segmented,
protected memory. Pointers carry special qualification values
(a sort of access control list, as it were, or a "capability "
as it is usually called in other systems); pointers to code
are *much* larger than pointers to data.


Another good example is the Cray vector machines (T90, SV1, et al).
As far as the C compiler is concerned, bytes are 8 bits, but all
integer types other than the char types are 64 bits. Native addresses
point to 64-bit words. A byte pointer is formed by storing a 3-bit
byte offset in the high-order bits of a 64-bit word pointer. Pointer
arithmetic works just fine, but I've seen non-portable code that tried
to do arithmetic on a pointer by casting it to an integer type,
performing integer arithmetic on it, and casting it back. It didn't
work.

--
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 #114
Sheldon Simms <sh**********@y ahoo.com> 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.

I understand that you might not see why it matters one way or
the other, but there is a good reason to be precisely correct
right from the start: it prevents you from making lazy assumptions
that might not bite you now, but that probably will bite you
later.


Indeed, I just posted elsewhere on this thread a concrete example of
code that failed on a certain platform precisely because a pointer is
*not* just an integer on that platform. (The platform was a Cray T90.
A byte pointer on that platform is a 64-bit word pointer with a byte
offset stored in the high-order 3 bits. The code tried to convert the
pointer to an integer and perform arithmetic on the integer
representation. )

On many (most?) current systems, pointers are actually implemented as
integers. If you examine a pointer with a debugger, or cast it to an
appropriate integer type and print its value, you'll see something
that looks like a numeric hardware address (actually a virtual address
in most cases). If you let this observation lead you to assume that
pointers are *always* just integers, you're likely to make mistakes
like the one I described. If, on the other hand, you think of a
pointer (or an address) as an abstraction that may or may not be
implemented as an integer, you'll have a better understanding of
what's really going on.

A pointer, as the name implies, points to something. How it does so
is usually not something you need to worry about (though knowing the
target-specific details can be useful when you're tracking down a
problem). If it points to an array, you can perform arithmetic on it
to point to other parts of the same array. If two pointers point to
two distinct objects, you can ask whether the pointers are equal, but
there's no much else you can safely do with them. All these things
are derived from the abstraction of what a pointer is as defined by
the C language; you won't get this from an assumption that a pointer
is an integer.

What I'm arguing is not that you shouldn't know the underlying
details; that knowledge can certainly be useful, and can lead to a
clearer understanding of why the abstractions are defined the way they
are. What I'm arguing is that you should avoid *depending* on the
underlying details. The programmer who made the mistake I mentioned
above did so because he assumed that the underlying details of one
platform applied everywhere; I was able to track down the problem
because I knew the underlying details of the platform on which the
code failed, and how to avoid depending on them.

--
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 #115
"Roose" <no****@nospam. nospam> wrote in message
news:Z5******** **********@news svr14.news.prod igy.com...
Before responding, [snip]


Please don't top-post.
Nov 13 '05 #116
"Roose" <no****@nospam. nospam> wrote in message
news:W0******** ***********@new ssvr21.news.pro digy.com...
Let me preface [snip]


Please don't top-post.
Nov 13 '05 #117
> Roose would be much less maligned if he would surround his
explanations with "non-precise" cavils. An unnamed number of
decades ago I had a very good mathematics instructor, who often
preceded some explanation with "this is not exact nor complete,
but it gives the general flavor. Later we will return and develop
some real proofs".
I've made many such statements like that. Go back and read the posts. Note
the use of the word "pretend", and "I _know_ this is not true on many
machines, but the idea is to give him a general idea without getting bogged
down in details."

People would be well advised to learn the assembly language of a
simple processor. About the simplest is the PDP-8, while a more
complex machine is the 8080. I am omitting things like the 8008
because they are non-extendible, while the above two have complete
instruction sets which can be made to do many things with suitable
hardware. MIX belongs in there somewhere also.
I agree it would be "well advised." However, his real goal is to learn C.
You can easily get discouraged with the details of assembly language,
especially with the tools most people have available. That is why I suggest
it is nice to learn a simple model.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

Nov 13 '05 #118
Let me just dispatch all of these flames toward Alan about me being a troll,
and his judgement and whatnot, with one comment...

It's completely transparent. If I were a troll, then you just let common
sense run its course. It's because you think I actually something valuable
to say, that competes with your jack-off C standard knowledge, that you must
repeatedly, vehemently insist that I'm a troll.

And, to which I would respond, as in the previous thread -- if I'm a troll,
then follow your own netiquette and killfile me. I don't care to be
responded to by people who don't think that I have something valuable to
say.

Note that you can killfile me, safe with the knowledge that there will be
plenty of others to nitpick. Really.

I'm not just addressing Grausewitz here, but everyone who is flaming Alan
for killfiling one of your Gods.

Roose

P.S. by jack-off, I don't mean technically wrong or even uninteresting, just
that it's obviously not helping the bigger picture. It just serves to show
off to everyone how much you know.

"Irrwahn Grausewitz" <ir*******@free net.de> wrote in message
news:7a******** *************** *********@4ax.c om...
Alan Connor <zz****@xxx.yyy > wrote:
What Roose posted was very helpful to me.

I am not going to dismiss an obviously intelligent and learned person on
your say so.


You enjoy to be fed by an obvious troll? Happy proceedings.
--
Irrwahn
(ir*******@free net.de)

Nov 13 '05 #119

"Richard Heathfield" <do******@addre ss.co.uk.invali d> wrote in message
news:bo******** **@sparta.btint ernet.com...
[top-posting fixed]
Richard wrote: I only post replies to you when it is necessary to correct your errors. If
you don't write articles, you won't make errors, so it won't be necessary
to correct them.

I think you've stumbled across a big time-saver. Well done.


Just answer the questions. They shouldn't be that hard for you. That is,
if you're going to keep nitpicking -- otherwise feel free to ignore
_everything_ I post.

--
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 #120

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.