473,842 Members | 1,863 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 21966
On Mon, 03 Nov 2003 14:39:22 +0000, Thomas Stegen <ts*****@cis.st rath.ac.uk> wrote:


Alan Connor wrote:
Thanks for the effort, but I'm still not exactly sure what an object is.


(A bit informal here)
You can say that a variable has two parts. A name and somewhere
to stay in memory. The name is an identifier and the part that
is stored in memory is the object.

So if you do this:

int i;

You will get an area of memory where you can put values by
doing stuff like i = 3; i is the name of this area of storage.

So you can say that an object is the actual area of memory
where the values of the variable is stored.

--
Thomas.


Thanks Thomas.

--
Alan C this post ends with w
q
Nov 13 '05 #81
On Mon, 03 Nov 2003 17:12:11 GMT, pete <pf*****@mindsp ring.com> wrote:


Alan Connor wrote:
Thanks for the effort,
but I'm still not exactly sure what an object is.
An object is a region of contiguous memory,
allocated by the program.
The address of a register qualified object,
may not be accessed by the program,
so everything that has to do with the addresses of objects,
does not apply to register objects.


What's a "register (qualified) object"?
There's three main ways of allocation:
1
int object_1 = 0;
object_1, is an ordinary variable.
2
char *pointer_1 = "object_2";
char *pointer_2 = "object_2";
"object_2" is paradoxically, the name of an anonymous object.
pointer_1 and pointer_2, may or may not point to the same object.
3
pointer = malloc(sizeof object_3);
malloc returns either NULL,
or a pointer to an anonymous and typeless object.

The value of an object depends on the bit pattern in the object
and on the type of identifier used to access the object.
An object may be accessed safely by any type of identifier
as long as:
1 the size of the type of the identifier
doesn't excede the size of the object,
2 and there are no conflicts with the type of the pointer
and the alignment of the object,
3 if being read, the bit pattern read from the object,
is defined for the type of the identifier.

(*(unsigned char*)&object_1 == 0)

A pointer to any object, when cast to a pointer to char,
signed or unsigned, points to the lowest addressable byte
of the object.
The addresses of any two objects may be compared for equality
or inequality.

("object_2" != (char*)&object_ 1)

The addresses of any two bytes within the same object,
as well as the address of the very next byte after an object,
may also be compared with each other for greater than or less than.

((char*)&object _1 + sizeof object_1 > (char*)&object_ 1)

The greater than or less than comparison of the addresses
of two bytes in unrelated objects, is undefined.

/* ("object_2" > (char*)&object_ 1), Undefined */

--
pete


Most of that was over my head, pete. But thanks for the effort.
It will be in the archives when I'm ready for it.

--
Alan C this post ends with w
q
Nov 13 '05 #82
On Mon, 3 Nov 2003 18:20:31 +0000 (UTC), Richard Heathfield <do******@addre ss.co.uk.invali d> wrote:


[top-posting fixed]
Richard wrote:

<snip>

Roose wrote:
Before responding, I'd appreciate it if you answer the questions you
ignored from my posts... otherwise I'm not going to bother responding to
your post, either.


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.


Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.

Killfiled for N days.

I'm into saving time too.

--
Alan C this post ends with w
q
Nov 13 '05 #83
On Mon, 03 Nov 2003 20:39:38 GMT, Alan Connor <zz****@xxx.yyy > wrote:
On Mon, 03 Nov 2003 17:12:11 GMT, pete <pf*****@mindsp ring.com> wrote:


Alan Connor wrote:
Thanks for the effort,
but I'm still not exactly sure what an object is.


An object is a region of contiguous memory,
allocated by the program.
The address of a register qualified object,
may not be accessed by the program,
so everything that has to do with the addresses of objects,
does not apply to register objects.


What's a "register (qualified) object"?


register int SomeThing;

as opposed to

int SomeThingElse;

Given
int *PointerToSomet hing;

you can
PointerToSometh ing = &SomeThingEl se;
but not
PointerToSometh ing = &SomeThing;
because SomeThing is a register qualified object, but SomeThingElse is not.

--
Lew Pitcher
IT Consultant, Enterprise Technology Solutions
Toronto Dominion Bank Financial Group

(Opinions expressed are my own, not my employers')
Nov 13 '05 #84
On Mon, 03 Nov 2003 05:50:46 GMT, Roose <no****@nospam. nospam> wrote:


Let me preface this with some meta-comments. If your goal is to learn C, by
all means go ahead and dive right into the C language. You only learn by
making mistakes. But is a common fact in computers that you really only
master something when you have at least learned the level below it, i.e.
_what it is abstracting_. Then you see where the abstraction came from.

See these articles:

http://www.joelonsoftware.com/articl...tractions.html
http://biztech.ericsink.com/Abstraction_Pile.html

Will do.
So if you configure OSes, it's good to learn some scripting. If you script,
good to know some compiled programming. If you program C, good to know some
assembly/computer architecture.

Yes!

The idea was to give a simple concrete model that anyone can learn, but
don't get bogged down if your real goal is to learn C. Basically what I'm
describing is a von Neumann machine with some details (this is a very
influential hardware architecture that created the descendants of PCs,
roughly). Unfortunately with a cursory google search, I couldn't find any
good links for that, maybe someone else can help out here.
> Basically you have a CPU which has a clock say every microsecond if you're > on a gighertz machine.
Wouldn't that be "nanosecond "?


Yes, whoops.
> 1. load them both from memory to CPU registers
> 2. execute the add instruction and specify those two registers
> 3. store the result back to memory
>


So memory is just dumb storage. I didn't realize that.


Yes, you can think of it as inert. The CPU controls everything, the
"brain". Memory is a separate unit which just stores bits. Same with the
hard disk. Notice that as the access time increases, so does the size of
the medium.
> Memory is just a big array of bytes. If you have 1 gig of memory, pretend > it is addressed 0 .. 0x3FFFFFFF. This is 2^30-1, or 1 gig. 0xFFFFFFFF is >> > 2^32-1, which means 4 gigs. If you have heard Apple's stupid
advertisements > that you can have more than 4 gigs of RAM in their PCs, that is because they > use more than 32 bits for pointers (i.e. the G5's 64-bit).


Don't get THAT at all, but that's okay for now.


The main point here was that a pointer is a C language abstraction (for an
address in memory). A pointer at the hardware level _is an integer_.
Memory is just a big array of bytes again. Say you have 1 meg of memory,
then you can just number the bytes 0 .. 1,048,575 (2^20-1). Suppose you
have a variable numFiles that is the number of files in a directory = 55.
That variable must be stored somewhere. Say it is stored at the 200,005th
byte. Then a pointer to numFiles would have the numeric value 200,004 (get
used to indexing from 0 in C). That's it. Nothing else. It's like an
array index if you think of the array as all of memory.

e.g.
int numFiles = 55;
int* pNumFiles = &numFiles; // pNumFiles is a variable of pointer
type, with the numeric value 200,004

Of course, as always, there are details, but I'm not going to clutter up
that simple concept with them. And this is very real, you can inspect
pointers in a debugger and see this (which was my suggestion).

Say you have a 32 bit register. After you learn binary/hex, you will see
why the number of different integers you can store in 32-bits is 2^32 = 4
gigs. A pointer can be thought of as an integer index, like I said. Thus
if a pointer is 32-bits, then you can only address 4 gigs of memory.
In your previous post you recommended that I learn hexadecimal (which I
have a slight handle on: 0-9-F with one character to describe identify
a nibble.

By this you mean learning to convert it to decimal, right?


You don't actually NEED to in order to do the exercise I suggested, since
many debuggers will display all values in decimal, but it helps to get into
the mindset. It is pretty simple if you are even mildly mathematical. Hex
is really a shorthand for binary, in some sense. There are probably plenty
of tutorials on the web, but afterwards you should be able to understand
these common equivalences:

2^8-1 = 255 = 0xFF = 1111 1111
2^8 = 256 = 0x100 = 1 0000 0000 = 0.25 K
2^16-1 = 65535 = 0xFFFF = 1111 1111 1111 1111 (spaces in binary added for
clarity)
2^16 = 65536 = 0x10000 = 1 0000 0000 0000 0000 = 64 K

0x1 = 0001 b
0x2 = 0010 b
0x4 = 0100 b
0x8 = 1000 b

0x1 = 0001 b
0x3 = 0011 b
0x7 = 0111 b
0xF = 1111 b
> Also, you know that if's and goto's can be substituted for all for and while > loops.


I do?


Yes, try taking a simple for loop or while loop and doing the exact same
thing with if's and goto's, if you don't see it right away. Of course this
is very bad programming practice, since loops make your logic more much
clearer to the reader.

(If you're not totally familiar with loops in general, you might want to try
a higher-level language like Python/Java/C# before attempting C.)


Nah. I've written hundreds of for,while,until loops in sh.
Sounds like the b command in sed. (oops! The b command in sed must be
like the jump instruction in C :-)


Well "jump" is an assembly term for specific CPU instructions. Goto is the
equilavent in C. My point was that for and while loops compile down to
jumps and tests (instruction that return true or false, basically).
Singe the hair off their balls: I'm getting a lot out of this.

It's really hard to learn the basics of anything if you get too bogged

down
in exactness.


Good, I'm glad. This confirms an observation developed from some years of
teaching. Exactness isn't necessarily the problem, but you just have to
know WHAT you need to be exact about (i.e. not irrelevant details like
rarely used terminology).

Let me close with some more high level observations. What does C add on top
of this model (besides nice syntax, I'm talking ideas here)?

1) Platform independence -- instead of writing in native assembly, you write
in C, and then compilers for every platform translate your C program into a
stream of instructions (just byte data)


Good. That's an important piece of the puzzle.
2) Constructs like functions, for and while loops, if's and switches, to
organize this enormous stream of instructions
All of this is found in sh, some of it being called "flow control".

(except maybe "switches" do you mean options to the compiler/assembler?)
3) A strong type system -- this can be confusing at first This is why I wanted to emphasize that pointers are just integers in
hardware. They're a C language construct. Same thing with characters/
character strings. Now floats ARE actually different in hardware, but we
won't get to that.
4) some other stuff which I don't care to think up now : )

The point of the type system is to catch mistakes at an obvious level.
Compiling a C program to see if all the types match up can catch a lot of
mistakes. It's sort of a sanity check, and it helps you structure your
program.

Don't really get that, but it *feels* important. Errr....Can you say
"feel" on a programming newsgroup? :-)
But again, you can read all you want, but if you can pull off the exercise
with the debugger I suggested, you will learn a whole lot.

It'll happen.
Roose


Thank you again. Back to K&R and the Answer Book and I'll check out those
websites in due course.

Got really fed up with the Richard fellow. Killfiled his arrogant ass for
a while.

--
Alan C this post ends with w
q
Nov 13 '05 #85
Alan Connor <zz****@xxx.yyy > wrote:
On Mon, 3 Nov 2003 18:20:31 +0000 (UTC), Richard Heathfield <do******@addre ss.co.uk.invali d> wrote:

<snip>
Roose wrote:
Before responding, I'd appreciate it if you answer the questions you
ignored from my posts... otherwise I'm not going to bother responding to
your post, either.


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.


Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.

Killfiled for N days.

I'm into saving time too.


You call Heathfield a troll? Bwhm. Bwhmhe. Bwhmhehehehe.
Bruahahahahahha aaahahahahaahaa aaaahhaha <gasp> gnihihihihi.

You haven't been reading c.l.c for more than two days, have you?
--
Irrwahn
(ir*******@free net.de)
Nov 13 '05 #86
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 #87
Alan Connor <zz****@xxx.yyy > wrote:
On Mon, 03 Nov 2003 18:40:15 GMT, CBFalconer <cb********@yah oo.com> wrote:

<snip>
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 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?!?

<snip>
--
Irrwahn
(ir*******@free net.de)
Nov 13 '05 #88
In article <el************ ******@newssvr1 4.news.prodigy. com>
Roose <no****@nospam. nospam> writes:
... I do program on wildly different architectures -- PS2, GameCube,
and XBox, each of which have more than one processor and memory space. ...


I would not call them "wildly different". The XBox uses an Intel
x86-type CPU as its main driver; the GameCube has a PowerPC CPU;
and the PS2 has a MIPS CPU. The latter two are traditional
register-oriented RISCs (although the PowerPC has a bizarre
instruction set, to anyone used to Intel and MIPS and even old IBM
370 assembly -- but not as bizarre as HP-PA or Itanium, if you ask
me). The Intel type CPU is common as dirt these days, of course.

Moreover, while game consoles do have specialized hardware (such
as special video RAM and "outboard" 3D transform engines), all
of these machines still have conventional linearly-addressed memory
for the CPUs to use, and the CPUs use it in conventional linear
fashion. And of course, all three of these are game consoles,
so they have the same ultimate goals, which results in remarkable
similarities of design.

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.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #89
Alan Connor wrote:
Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.

Killfiled for N days.

I'm into saving time too.


Alan...

Wow! I'm impressed by your judgment. Richard has been one of the
most highly regarded regulars of comp.lang.c for some years now.
He's earned the professional (and personal) respect of many of
the best C programmers in the world, been recognized by Don Knuth
for spotting an error and providing a correction to "The Art of
Computer Programming", co-authored the book "C Unleashed" with
some of the most knowledgeable regulars here, and provided really
high-quality help to an awesome number of newbies (and a large
number of not-so-newbies, including myself) - all under the
scrutiny of expert peers who delight in picking nits - especially
when they're aware the poster /really/ knows his stuff.

I did say "impressed" . I didn't say "favorably impressed". I
think I'd be honored if you called me deceitful and sophomoric
and a troll and killfiled me, too. I don't post as frequently as
Richard; but it /would/ save you at least some small amount of time.
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall very far from the tree.

Nov 13 '05 #90

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.