"Mastering C Pointers"....
maniac
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
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
>
> 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
It has a lot of basic C stuff too.
"Andy" <mani...@bellsouth.net> wrote in message
news:YKSob.10682$BX....@bignews5.bellsouth.net...
Michael Str.
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
Your eyes are more precious than $25USD, so I suggest you buy the book.
In fact, that book is worth reading.
Sheldon Simms
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.
--
Richard Heathfield : bin...@eton.powernet.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
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.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Richard Heathfield
> Richard Heathfield wrote:
>>
> ... 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.
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.
>
<snip>
>
> 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
>
>
> maniac wrote:
>
>> 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.
>
Richard,
Would you mind defining "object" for a shell scripter just starting to
learn C?
(I've saved this pointer article. Thanks.)
--
Alan C this post ends with w
q
Malcolm
"Alan Connor" <zzz...@xxx.yyy> wrote in message
>
> Would you mind defining "object" for a shell scripter just starting to
> learn C?
>
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
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
--
Irrwahn
(irrw...@freenet.de)
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
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
[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.
--
Thomas.
Irrwahn Grausewitz
[top-posting and quoting fixed]
> Alan Connor <zzz...@xxx.yyy> wrote:
> > Would you mind defining "object" for a shell scripter just starting to
> > learn C?
> In C, there is no technical term "object",
Of course there is. References: C99 3.14, C89 1.6
> but he means anything which
> occupies memory can be pointed at. Any code (a function, individual CPU
> instructions)
C has no notion of CPU instructions. In C objects and functions are
quite different beasts. For example
- function types are distinct from object types.
- function code does not necessarily reside in data storage area,
thus pointers to objects and pointers to functions are not
portably interchangeable
- application of the sizeof operator to a function designator is a
constraint violation.
- ...
> or data (a simple int, char; an array; a struct or union; a
> block of malloc'd memory) can be pointed at.
^^^^^^^^^^^^^^^^^^^
Better: ... can be designated by an lvalue.
<stuff not related to the definition of objects in C snipped>
--
Irrwahn
(irrw...@freenet.de)
Irrwahn Grausewitz
<snip>
> I'm trying to help the guy learn.
This is best done by providing *correct* information.
--
Irrwahn
(irrw...@freenet.de)
Richard Heathfield
> I know you still hold a grudge
Wrong.
> for being so thoroughly embarassed,
Wrong.
<snip>
> 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.
No, it tells me that you haven't even bothered to read the industrial
standard that defines the language you are using. That casts some doubt on
your use of the word "professional".
> Also it's common for programmers to program in both C and C++,
True.
> so using the term object in C is confusing.
On the contrary, the word means the same in C++ as it does in C. Look it up
in ISO/IEC 14882:1998 if you don't believe me.
> It's not an important word at all in C, but
> very important in C++.
Wrong. It's a *vital* word for those who wish truly to understand C.
<snip>
Simon Biber
[...]
> 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 */
Constraint violation - Incompatible types in assignment.
[...]
> That's it. Pointers are really that simple.
Perhaps not. :-)
--
Simon.
Richard Heathfield
> "Richard Heathfield" <dont...@address.co.uk.invalid> wrote:
> [...]
>> 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 */
>
> Constraint violation - Incompatible types in assignment.
Yes, a typo, already corrected elsethread. No, I didn't notice it myself.
>
> [...]
>
>> That's it. Pointers are really that simple.
>
> Perhaps not. :-)
Oh, *pointers* are simple - it's *typing* that's difficult. :-)
Andy
Why has this turned into a battle.
I understand regardless what object is sopposed to be.
We are just starting up, weather object is defined in the C standard
or not, doesnt really make a difference.
thanx to all for the help
Roose
"Andy" <mani...@bellsouth.net> wrote in message
news:ptcpb.14975$un....@bignews6.bellsouth.net...
> Why has this turned into a battle.
> I understand regardless what object is sopposed to be.
> We are just starting up, weather object is defined in the C standard
> or not, doesnt really make a difference.
>
> thanx to all for the help
Well, that's the way this newsgroup is. My point is, that if you go to your
average company with a bunch of C programmers, you will rarely if ever hear
them talking about objects in this sense. If you ask them about them, it's
likely they would say something like "There are no objects in C++".
Which doesn't make them right, but the point is communication, not rigid
technical definitions.
Joona I Palaste
> "Andy" <mani...@bellsouth.net> wrote in message
> news:ptcpb.14975$un....@bignews6.bellsouth.net...
>> Why has this turned into a battle.
>> I understand regardless what object is sopposed to be.
>> We are just starting up, weather object is defined in the C standard
>> or not, doesnt really make a difference.
>>
>> thanx to all for the help
> Well, that's the way this newsgroup is. My point is, that if you go to your
> average company with a bunch of C programmers, you will rarely if ever hear
> them talking about objects in this sense. If you ask them about them, it's
> likely they would say something like "There are no objects in C++".
No one ever said there were no objects in C++. If you're going to
attack others' arguments, please at least try to attack arguments they
really made.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"'So called' means: 'There is a long explanation for this, but I have no
time to explain it here.'"
- JIPsoft
Roose
"Thomas Stegen" <tst...@cis.strath.ac.uk> wrote in message
news:3fa4f698$1...@nntphost.cis.strath.ac.uk...
> 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.
You're right, there is nothing wrong, and I admitted I was wrong already.
As far as tone, I'm just responding in kind.
> The grudge seems to be on your side FWIW.
Not really, I wasn't the one who needed the last word in the other thread.
I pretty much ended it out of boredom when Richard felt the need to turn it
into a child's game.
Roose
"Irrwahn Grausewitz" <irrw...@freenet.de> wrote in message
news:r1u9qv01q4nf0ompq...@4ax.com...
> "Roose" <nos...@nospam.nospam> wrote:
> <snip>
> > I'm trying to help the guy learn.
>
> This is best done by providing *correct* information.
Actually, it's best done by giving someone something to _do_, rather then
telling them information. Which is what I did.
Information that isn't relevant only confuses. Besides, the term object is
just a name, i.e. your statement is a synthetic fact (as opposed an
analytic). If you don't know what I mean, go read some philosophy. I
didn't know what an object is in C until now, and I have programmed
successfully for many years, shipped many products, etc. It doesn't matter.
Nobody has ever learned anything by reading a bunch of facts. They learn by
doing. If the OP does what I told him to do successfully, he will have gone
A LOT farther toward being a professional programmer in C then if simply
reads all of the "definitions" post.
Roose
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.
>
> No, it tells me that you haven't even bothered to read the industrial
> standard that defines the language you are using. That casts some doubt on
> your use of the word "professional".
Give me a break. This is EXACTLY why CLC should not be just about standard
C, and CLC.moderated should have that sole responsibility. Regardless of
whether they're right for coming here, there are TONS of newbies that do.
And then they get these rigid, exacting answers filled with irrelevant
technical details, which you would never hear in the real world. Then they
get turned off to C and think it's for wankers. A LOT of people actually
think this.
I don't doubt that you are technically correct. Just like I didn't in the
interview thread. But your insistence on expounding on all these
trivialities obscures the real question. Getting a job, or learning how to
write a real program that does what you want it to do.
> > so using the term object in C is confusing.
>
> On the contrary, the word means the same in C++ as it does in C. Look it
up
> in ISO/IEC 14882:1998 if you don't believe me.
It may technically, but not in colloquial usage. If you start blathering
about objects in C at work, some people will be confused, and others might
wonder why you're being such a pedant. Some people might think you're
talking about objective C, or C++, or emulating object-orientation in C,
etc.
>
> > It's not an important word at all in C, but
> > very important in C++.
>
> Wrong. It's a *vital* word for those who wish truly to understand C.
Maybe for understanding the C standard. It is not vital for those who
simply wish to write successful programs, me being an example of that. See
the other post too -- this is a synthetic fact and not analytic. Analytic
facts tend to be the ones where if you don't know them, then you can't do
what you need to do.
Roose
Roose
to read between the lines.
Joona I Palaste
>> attack others' arguments, please at least try to attack arguments they
>> really made.
> I meant "C" of course, not "C++". I know it's hard with such a literal mind
> to read between the lines.
Skipping over the fact that you're still top-posting (corrected in this
reply), not using proper attributions and quoting signatures, let's get
to the point...
First, no one ever said there were no objects in C. My previous advice
applies.
Second, a literal mind is pretty much a requirement on comp.lang.c.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"My absolute aspect is probably..."
- Mato Valtonen
Roose
> > block of malloc'd memory) can be pointed at.
> ^^^^^^^^^^^^^^^^^^^
> Better: ... can be designated by an lvalue.
That's better for you. Not better for a newbie. I would love to see some
beginner ask you about C programming, and you start blathering on about
lvalues.
..."insular little world of the C standard as a bible" ...
Damn I keep hearing echoes of my earlier posts again...
Roose
"Joona I Palaste" <pal...@cc.helsinki.fi> wrote in message
news:bo3q93$b8s$1...@oravannahka.helsinki.fi...
> Roose <nos...@nospam.nospam> scribbled the following:
> >> No one ever said there were no objects in C++. If you're going to
> >> attack others' arguments, please at least try to attack arguments they
> >> really made.
>
> > I meant "C" of course, not "C++". I know it's hard with such a literal
mind
> > to read between the lines.
>
> Skipping over the fact that you're still top-posting (corrected in this
> reply), not using proper attributions and quoting signatures, let's get
> to the point...
> First, no one ever said there were no objects in C. My previous advice
> applies.
You're not reading. I said if you asked typical workers in a real
programming house, they would say there are no objects in C.
> Second, a literal mind is pretty much a requirement on comp.lang.c.
OK, so at least you admit it. : ) Fair enough. Would you also admit to
"extremely regimented thought patterns"? : )
Joona I Palaste
> "Joona I Palaste" <pal...@cc.helsinki.fi> wrote in message
> news:bo3q93$b8s$1...@oravannahka.helsinki.fi...
>> Roose <nos...@nospam.nospam> scribbled the following:
>> >> No one ever said there were no objects in C++. If you're going to
>> >> attack others' arguments, please at least try to attack arguments they
>> >> really made.
>>
>> > I meant "C" of course, not "C++". I know it's hard with such a literal
> mind
>> > to read between the lines.
>>
>> Skipping over the fact that you're still top-posting (corrected in this
>> reply), not using proper attributions and quoting signatures, let's get
>> to the point...
>> First, no one ever said there were no objects in C. My previous advice
>> applies.
> You're not reading. I said if you asked typical workers in a real
> programming house, they would say there are no objects in C.
Whoops. I stand corrected. Technically, those workers would be lying.
More realistically, they would be speaking out of ignorance. I don't
think they would be lying *intentionally*.
The point is, though - here on comp.lang.c, it's the standard that
decides what the terms mean, not typical workers in a programming
house, real or not.
PS. Please stop quoting my signature. Thanks.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Hasta la Vista, Abie!"
- Bart Simpson
Alan Connor
>
>
> Alan Connor wrote:
>
>> 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;
>
got it ^
Thanks to everyone that responded here with helpful advice:
Malcom
Roose
Irrwahn
Simon
The concept of "object" is much clearer. (as are local battlelines :-)
I do wonder why K&R didn't find it important enough to include a reference
to it in the index to the 2nd Edition....
Whereas Roose's explanation of "object" wasn't quite as useful as the one
above, I was very much attracted to his ideas about anchoring the abstract
in the real world of cpu registers and such.
Perhaps it wouldn't be a bad idea to learn a little assembly language at
this point?
(does that even make sense?)
May I also point out that quoting the ANSI standard to a novice is about
as useful as replying in Swahili :-)
Thanks again, Richard.
Mark McIntyre
<nos...@nospam.nospam> wrote:
>
>
>You're not reading. I said if you asked typical workers in a real
>programming house, they would say there are no objects in C.
No they wouldn't, not if they knew anything more than absolutely basis
C. You're talking bullsh*t.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Mark McIntyre
<mani...@bellsouth.net> wrote:
>Why has this turned into a battle.
Because people in this group prefer correctness to incorrectness, and
Roose has spent the last week arguing about things he/she
misunderstands, or has otherwise wrong ideas about. And now everyone
is p*ssed off at him/her and therefore picks on every little error.
Mark McIntyre
<nos...@nospam.nospam> wrote:
>Not better for a newbie. I would love to see some
>beginner ask you about C programming, and you start blathering on about
>lvalues.
And whats wrong with learning the techncal words that help define the
language you're using? The concept of an lvalue is very useful in C.
Richard Heathfield
> [...] the point is communication, not rigid technical definitions.
It is to facilitate effective communication that the rigid technical
definitions exist in the first place.
Roose
> to it in the index to the 2nd Edition....
Not to be redundant, but this is probably because it is not common in
colloquial usage among C programmers. It probably exists to give compiler
writers a convenient term for a general idea, which the regular C programmer
needn't be concerned with.
> Whereas Roose's explanation of "object" wasn't quite as useful as the one
> above, I was very much attracted to his ideas about anchoring the abstract
> in the real world of cpu registers and such.
I'm glad you found it useful.
> Perhaps it wouldn't be a bad idea to learn a little assembly language at
> this point?
That might help, but you don't even need to learn a specific machine. You
can have a quite simplified model of what assembly language is and it will
be helpful in C programming. After all, it is different for each machine,
so you don't want to have _too_ specific an idea.
Basically you have a CPU which has a clock say every microsecond if you're
on a gighertz machine. A program is a stream of instructions (pretend they
are stored in 32 bits in a binary format). Pretend it is a big array of
bytes. You start at the beginning, and just drag through the stream. They
are executed as fast as possible on these discrete clock ticks. Some
instructions take more cycles than others. Adds are cheap (say they take 1
cycle), multiplies a little slower (2 cycles), divides slower (4 cycles).
These are numbers I pulled out of my ass, of course it's different on every
machine. You also have all the bitwise operators in C as single
instructions, more or less. You have floating point and integer
instructions. Character strings are arrays of integers (ASCII). Pointers
are integers as well.
There are instructions to load a word from memory into a CPU register, and
vice versa, to store a word from a CPU register to memory. Note that memory
accesses are much more expensive than arithmetic instructions (pretend 50
cycles on average). All the instructions only work on CPU registers. So to
add to integers in memory, you would have to:
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
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).
Also, you know that if's and goto's can be substituted for all for and while
loops. Loops are just a convenient abstraction. On the machine, they are
all implemented in terms of if's and goto's (called jumps in assembly
language, you jump from one instruction to another than is not sequential).
So basically the CPU drags through the instructions sequentially, until it
hits a jump instruction.
If you want to know about I/O, you'll have to learn about interrupts and
such, and I'll stop here because that is more than enough to absorb.
(Note: nitpickers will be flamed. I _know_ for a fact these things are not
all true on every machine, but is a convenient model, in the interest of
giving something _concrete_, again)
> May I also point out that quoting the ANSI standard to a novice is about
> as useful as replying in Swahili :-)
Indeed.
Roose
Richard Heathfield
>> > 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.
>>
>> No, it tells me that you haven't even bothered to read the industrial
>> standard that defines the language you are using. That casts some doubt
>> on your use of the word "professional".
>
> Give me a break.
Sure. Take a break, any time you like.
> This is EXACTLY why CLC should not be just about standard C,
That appears to be your opinion, but I see no supporting evidence for your
statement.
> and CLC.moderated should have that sole responsibility.
comp.lang.c.moderated is merely a moderated version of comp.lang.c
In comp.lang.c.moderated, I suspect that many of your articles would simply
not be approved by the moderator. Feel free to try to prove me wrong.
> Regardless of
> whether they're right for coming here, there are TONS of newbies that do.
Agreed.
> And then they get these rigid, exacting answers
Not exacting. Merely exact (modulo typographical errors).
> filled with irrelevant technical details,
You may consider the details irrelevant. I do not, however, pitch my answers
at your level of understanding, but at the questions actually asked by real
people. When the details matter, I give the details. When they don't, I
don't. Now, you may have considered my answer to be overly technical, but
it's a walk in the park compared to the answer I /could/ have given. I
included as much detail as I considered the OP could reasonably be expected
to take in (in one sitting), together with a little encouragement that it
really isn't as hard as he's been led to believe. I continue to maintain
that this was an appropriate response to his question.
> which you would never hear in the real world.
Well, actually, I do discuss such (relevant) technical details in the real
world, as well as on Usenet. And anyway, what makes you think that Usenet
is not part of the real world?
> Then they
> get turned off to C and think it's for wankers.
Speculation. I've found that people often respond well to being told the
underlying truth, rather than the helicopter-joystick method of
programming: "fiddle with the program, and watch what the computer does,
because if you want it to do that again, that is the code you have to
write" is not a very satisfactory way to learn programming.
> A LOT of people actually think this.
Well, I will accept that /you/ think it. Since you have already acknowledged
that you don't exist, however, your view probably doesn't count for much.
> I don't doubt that you are technically correct.
Fine, so what's the problem here?
> Just like I didn't in the interview thread.
Wonderful.
> But your insistence on expounding on all these
> trivialities
If they're such trivialities, why did you get them wrong?
> obscures the real question. Getting a job, or learning how
> to write a real program that does what you want it to do.
That wasn't the real question. The real question was about pointers.
>> > so using the term object in C is confusing.
>>
>> On the contrary, the word means the same in C++ as it does in C.
>> Look it up in ISO/IEC 14882:1998 if you don't believe me.
>
> It may technically, but not in colloquial usage.
Then colloquial usage is wrong, and should be changed.
> If you start blathering
> about objects in C at work, some people will be confused, and others might
> wonder why you're being such a pedant.
Actually, I don't think I've ever confused or offended anyone in a workplace
situation by referring to objects. As for the accusation of pedantry, I
cheerfully confess. Pedants make the best programmers.
> Some people might think you're
> talking about objective C, or C++, or emulating object-orientation in C,
> etc.
Yes, it's possible, and if they did think that, they'd be wrong. People are
wrong a /lot/. Get used to it.
>> > It's not an important word at all in C, but
>> > very important in C++.
>>
>> Wrong. It's a *vital* word for those who wish truly to understand C.
>
> Maybe for understanding the C standard. It is not vital for those who
> simply wish to write successful programs,
If one wishes to write /correct/ C programs, an understanding of the
principles laid out in the Standard is vital. The easiest way to achieve
this understanding is by reading and understanding the C Standard.
> me being an example of that.
We have yet to see any evidence of your ability to write successful
programs.
Richard Heathfield
> The concept of "object" is much clearer. (as are local battlelines :-)
>
> I do wonder why K&R didn't find it important enough to include a reference
> to it in the index to the 2nd Edition....
There is an entry for "object" in the index on page 268, which references
pages 195 and 197.
> May I also point out that quoting the ANSI standard to a novice is about
> as useful as replying in Swahili :-)
That's right. C is indeed a foreign language when you're a novice, just as
Swahili is a foreign language to a novice who is beginning to study
Swahili. And, just as the Swahili novice eventually begins to grasp the
language, so a C novice, in time, starts to make sense of C, and of the
Standard.
> Thanks again, Richard.
Any time.
nobody
news:ra5pb.1967$4i...@newssvr27.news.prodigy.com...
> In C, there is no technical term "object", [snip]
Please don't top-post.
nobody
> I know you still hold a grudge [crap snipped]
Please don't top-post.
nobody
> I meant "C" of course, not "C++". [crap "of course" snipped]
>
Please don't top-post.
Mark Gordon
Andy <mani...@bellsouth.net> wrote:
>
> > 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.
My experience is that the most common reasons for people having
difficulties understanding pointers are:
1) They think that pointers are difficult
2) The have been told that pointers are hard to understand
3) Pointers have been badly explained.
Of course, there are lots of complex things that can be done *with*
pointers, but the pointer itself is merely something that points
somewhere, and a pointer variable is just a variable that holds a
pointer.
> but I'll take your advice and ask here if I have more questions.
Questions are always welcome. However, you should check the FAQ (google
will find it for you) just in case any question is already answered
there in a manner you can understand.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Irrwahn Grausewitz
Please don't strip attributions. It's not clear to whom you are
responding.
> > > or data (a simple int, char; an array; a struct or union; a
> > > block of malloc'd memory) can be pointed at.
> > ^^^^^^^^^^^^^^^^^^^
> > Better: ... can be designated by an lvalue.
>
> That's better for you. Not better for a newbie. I would love to see some
> beginner ask you about C programming, and you start blathering on about
> lvalues.
This is /not/ alt.comp.lang.learn.c-c++. This is c.l.c. You don't like
it? Then leave it.
> ..."insular little world of the C standard as a bible" ...
In c.l.c the C standard /is/ the bible. The topics and conventions of
c.l.c are /not/ defined by your personal opinions.
> Damn I keep hearing echoes of my earlier posts again...
Sounds serious. You should contact a doctor.
--
Irrwahn
(irrw...@freenet.de)
Irrwahn Grausewitz
> "Irrwahn Grausewitz" <irrw...@freenet.de> wrote in message
> news:r1u9qv01q4nf0ompq...@4ax.com...
> > "Roose" <nos...@nospam.nospam> wrote:
> > <snip>
> > > I'm trying to help the guy learn.
> >
> > This is best done by providing *correct* information.
>
> Actually, it's best done by giving someone something to _do_, rather then
> telling them information. Which is what I did.
No. You provided incorrect information and got defensive when you were
corrected.
> Information that isn't relevant only confuses. Besides, the term object is
> just a name, i.e. your statement is a synthetic fact (as opposed an
> analytic). If you don't know what I mean, go read some philosophy.
In order to dicuss something you first have to get the terms right. If
you don't know what I mean, follow your own advice and go read some
philosophy.
> I
> didn't know what an object is in C until now, and I have programmed
> successfully for many years, shipped many products, etc. It doesn't matter.
Hopefully I never have to use one of those products.
> Nobody has ever learned anything by reading a bunch of facts. They learn by
> doing. If the OP does what I told him to do successfully, he will have gone
> A LOT farther toward being a professional programmer in C then if simply
> reads all of the "definitions" post.
Reread the thread: the poster asked for the definition of the term
"object" in the context of the C language. Why not answer his question
instead of gibbering?
--
Irrwahn
(irrw...@freenet.de)
Roose
>
> Sure. Take a break, any time you like.
Hilarious. Back to children's games, I see.
> In comp.lang.c.moderated, I suspect that many of your articles would
simply
> not be approved by the moderator. Feel free to try to prove me wrong.
As would many of yours.
> > filled with irrelevant technical details,
>
> You may consider the details irrelevant. I do not, however, pitch my
answers
> at your level of understanding, but at the questions actually asked by
real
> people. When the details matter, I give the details. When they don't, I
> don't. Now, you may have considered my answer to be overly technical, but
> it's a walk in the park compared to the answer I /could/ have given. I
> included as much detail as I considered the OP could reasonably be
expected
> to take in (in one sitting), together with a little encouragement that it
> really isn't as hard as he's been led to believe. I continue to maintain
> that this was an appropriate response to his question.
I'm not talking about your pointer response, which was generally good, as I
already said. I'm talking about the newsgroup in general. Read some of the
responses to newbies. See how helpful they are.
Even the first one in this thread was quite unhelpful. The guy was like "I
heard it was about Turbo C and MS-DOS -- that means you shouldn't read
it." -- with no further explanation. Do you think a newbie knows what that
means, or knows what Turbo C is (or even DOS)? A much more helpful response
would be along the lines of, "This book appears to be rooted in a particular
platform, one that happens to be outdated, and thus may confuse you with a
lot of information that you don't need to know."
> > which you would never hear in the real world.
>
> Well, actually, I do discuss such (relevant) technical details in the real
> world, as well as on Usenet. And anyway, what makes you think that Usenet
> is not part of the real world?
Stop with the sniveling wordplay already.
> > Then they
> > get turned off to C and think it's for wankers.
>
> Speculation. I've found that people often respond well to being told the
> underlying truth, rather than the helicopter-joystick method of
> programming: "fiddle with the program, and watch what the computer does,
> because if you want it to do that again, that is the code you have to
> write" is not a very satisfactory way to learn programming.
I agree that that's a terrible way to learn. Without the concepts, you're
just blindly hacking. That's why I specifically said that you need at least
TWO perspectives. I encourage them to read your article. My claim is that
that's not sufficient. They should read a concrete explanation like mine.
Together they will help you understand pointers.
Plus my article encouraged them to learn the abstract while being rooted in
the concrete, not to focus on the concrete at the expense of the abstract.
This is exactly like the top-post thread. You're so goddamn close-minded
that you think the only way to do everything is your own. I, on the other
hand, recognize that sometimes things needs multiple perspectives, and there
are multiple valid ways of doing things. Sometimes there is no right and
wrong, just personal preference. I know it's a lot to handle, since you
like rigid rules so much.
> > obscures the real question. Getting a job, or learning how
> > to write a real program that does what you want it to do.
>
> That wasn't the real question. The real question was about pointers.
OK, so do you think that the OP wanted just to study pointers for the sake
of dinner party conversation, or eventually write a real program? Again,
READ BETWEEN THE LINES. Jesus Christ.
> > It may technically, but not in colloquial usage.
>
> Then colloquial usage is wrong, and should be changed.
Q.E.D. Another perfect example of why my underemployed flames were so
accurate. Everybody else is wrong; and you're right. Yes. You can insist
on using the term object however you want. However the rest of the world
will continue to use a more useful definition. I guess Stroustrop and
Ritchie and all the people who use the term OOP are wrong. Since, of
course, by default you should assume when someone says "object" in C++, they
mean something that takes storage, and not something with a constructor and
destructor and all that.
Let me suggest that you are the one who needs to change.
> >> Wrong. It's a *vital* word for those who wish truly to understand C.
> >
> > Maybe for understanding the C standard. It is not vital for those who
> > simply wish to write successful programs,
>
> If one wishes to write /correct/ C programs, an understanding of the
> principles laid out in the Standard is vital. The easiest way to achieve
> this understanding is by reading and understanding the C Standard.
What percent of the total number of C programs in the world do you think are
correct in this sense?
Was your first C program correct in this sense? Would it have taken more
time and effort to make it correct, knowing what you knew then? What do you
think the OP is interested in doing, _at this stage in the game_? Do think
he is interested in reading the C standard, before having written anything
substantial or understanding pointers at a practical level?
No sarcasm there, just answer honestly.
Roose
Alan Connor
Mark: The limit for sigs on the Usenet is 4 lines and they need to be
immediately below a "-- " line.
Fix yours or I will have to killfile you.
What Newsfeed.Com is doing amounts to nothing but spam. Ditch them.
Alan Connor
>
>
>> I do wonder why K&R didn't find it important enough to include a reference
>> to it in the index to the 2nd Edition....
>
> Not to be redundant, but this is probably because it is not common in
> colloquial usage among C programmers. It probably exists to give compiler
> writers a convenient term for a general idea, which the regular C programmer
> needn't be concerned with.
>
>> Whereas Roose's explanation of "object" wasn't quite as useful as the one
>> above, I was very much attracted to his ideas about anchoring the abstract
>> in the real world of cpu registers and such.
>
> I'm glad you found it useful.
>
>> Perhaps it wouldn't be a bad idea to learn a little assembly language at
>> this point?
>
> That might help, but you don't even need to learn a specific machine. You
> can have a quite simplified model of what assembly language is and it will
> be helpful in C programming. After all, it is different for each machine,
> so you don't want to have _too_ specific an idea.
>
> Basically you have a CPU which has a clock say every microsecond if you're
> on a gighertz machine.
Wouldn't that be "nanosecond"?
A program is a stream of instructions (pretend they
> are stored in 32 bits in a binary format). Pretend it is a big array of
> bytes. You start at the beginning, and just drag through the stream. They
> are executed as fast as possible on these discrete clock ticks. Some
> instructions take more cycles than others. Adds are cheap (say they take 1
> cycle), multiplies a little slower (2 cycles), divides slower (4 cycles).
> These are numbers I pulled out of my ass, of course it's different on every
> machine.
One assumes that you washed them before posting :-|
You also have all the bitwise operators in C as single
> instructions, more or less. You have floating point and integer
> instructions. Character strings are arrays of integers (ASCII). Pointers
> are integers as well.
>
> There are instructions to load a word from memory into a CPU register, and
> vice versa, to store a word from a CPU register to memory. Note that memory
> accesses are much more expensive than arithmetic instructions (pretend 50
> cycles on average). All the instructions only work on CPU registers. So to
> add to integers in memory, you would have to:
>
> 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.
> 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.
>
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?
> Also, you know that if's and goto's can be substituted for all for and while
> loops.
I do?
> Loops are just a convenient abstraction. On the machine, they are
> all implemented in terms of if's and goto's (called jumps in assembly
> language, you jump from one instruction to another than is not sequential).
> So basically the CPU drags through the instructions sequentially, until it
> hits a jump instruction.
>
Sounds like the b command in sed. (oops! The b command in sed must be
like the jump instruction in C :-)
> If you want to know about I/O, you'll have to learn about interrupts and
> such,
>and I'll stop here because that is more than enough to absorb.
Well, I knew THAT at least.
>
> (Note: nitpickers will be flamed. I _know_ for a fact these things are not
> all true on every machine, but is a convenient model, in the interest of
> giving something _concrete_, again)
>
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.
>> May I also point out that quoting the ANSI standard to a novice is about
>> as useful as replying in Swahili :-)
>
> Indeed.
>
> Roose
>
>
I read this carefully, twice, consulting K&R for basic definitions.
At present I see each piece of hardware as having a control panel with
switches and dials (card) with the program deciding which switch to flip
or dial to turn, in what order...
Thanks again Roose. There is altogether too little practical talk in
the programming world, which makes it very hard for novices.
Alan Connor
It wasn't "gibbering", it was very helpful.
A lot more helpful than this.
Keith Thompson
[...]
> Basically you have a CPU which has a clock say every microsecond if you're
> on a gighertz machine.
To nitpick: a gigahertz machine would have a clock cycle every
nanosecond, not every microsecond.
--
Keith Thompson (The_Other_Keith) k...@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"
Chris Torek
Alan Connor <xx...@yyy.zzz> writes:
>So memory is just dumb storage. I didn't realize that.
Good, because there are machines on which this is not the case. :-)
C's model (of "objects" and values) does require that plain old
"dumb storage" memory *exist*, but it permits "smart storage" too,
and on machines that have it, compilers are allowed to use it.
(There is an important and interesting -- but alas, off-topic in
c.l.c -- class of machines with "atomic memory" on which various
forms of lock-free parallelism are possible.)
>On Sun, 02 Nov 2003 21:30:37 GMT, Roose <nos...@nospam.nospam> wrote:
>>Memory is just a big array of bytes. If you have 1 gig of memory,
>>pretend it is addressed 0 .. 0x3FFFFFFF. ... 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.
I am not sure which part you "don't get", but be aware that this,
too, is not required of systems that will run C, and indeed, there
are systems on which it is not true, or at least only partly true.
One of them was very common only a decade ago: the 80x86 CPU in
the ordinary IBM PC has non-linear ("segmented") addressing, and
in 16-bit modes -- which are no longer used for much, but were all
one had until the 80386 came out -- a memory address was made up
of segment:offset pairs.
Of course, actually using this to good effect was slow at best,
and a lot of old C compilers for the x86 used bizarre modifiers
(spelled "far" and "near" in some cases; now more like _FAR and
_NEAR in backwards compatible modes) to let you mix "fast" code
that avoided the use of segments with "slow" code that used segments
so as to be able to break the "64K barrier" (or rather, 128K, with
64K of code and 64K of data, in a split I&D design reminiscent of
some PDP-11s, where C was originally developed).
All C really requires of memory is that it be able to store values,
and that it be "addressable" in some way. Which is where the pointers
that are in the "subject:" line here come in -- taking the address
of a memory region holding a C "object" yields a pointer to that
object.
Actually, C does impose a few more conditions on memory. In
particular, C requires that arrays be (or at least seem to be)
contiguous. An array is defined by its "element type" and a numeric
size -- in C89, an integer constant like 42 -- and an array must
be stored in memory as a contiguous sequence of that many of those
elements. Each element is itself an "object" (region of storage),
but the array as a whole is an object too, just a composed one.
If all of a given computer's memory is one big blob of bytes in
sequence, which is certainly an easy way to build a computer, then
it is equally easy to divide up this one blob any way you like.
But C does allow other arrangements, which can have add security
or reliability features for instance, as long as the resulting
memory can be grouped together to hold arrays. Other than those
arrays, there is no *requirement* that there be a neat numerical
sequencing of "all memory"; it just happens to be pretty common,
because it is so easy.
(As an aside: on modern operating systems, "memory" is usually an
illusion anyway. The OS will *simulate* a nice linear sequence of
bytes, but it does so with "pages" that are "paged in" and "paged
out" to/from some form of "backing store" -- typically on disk --
and shuffled and reshuffled without any individual program, whether
coded in C or any other language, being able to see what is happening.
The hardware must provide a certain amount of assistance to let
the OS know what a program is trying to do, and the OS then determines
whether the code is doing something "normal" and "allowed", and if
so, arranges to allow it. The OS can then also determine whether
the program is running amok, and if so, stop it. While large chunks
of OSes can be written in nothing other than strictly conforming
C code, parts *must* be written using stuff outside the C standard,
and often must be hand-coded in assembly. These include the parts
that talk with hardware to find out what the various user programs
are attempting.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.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.
Richard Heathfield
>> I do wonder why K&R didn't find it important enough to include a
>> reference
>> to it in the index to the 2nd Edition....
>
> Not to be redundant, but this is probably because it is not common in
> colloquial usage among C programmers.
On the contrary, it's simply a false statement. The term /is/ in the index
of K&R2.
Lew Pitcher
> On Sat, 01 Nov 2003 21:12:00 -0800, Larry Niven wrote:
>
>
>>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.
"The Magic Goes Away" is worth reading.
It sounds like "Mastering C Pointers" isn't worth reading at all.
P'haps Larry should ask Jerry P about C pointers ;-)
--
Lew Pitcher
Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
Richard Heathfield
>> > Give me a break.
>>
>> Sure. Take a break, any time you like.
>
> Hilarious. Back to children's games, I see.
No. I am not a mind-reader. I answer to what you say, not to what you might
or might not mean. You asked me to give you a break, and I'm happy to
oblige. If you have a problem with taking a break, why ask me for one?
>> In comp.lang.c.moderated, I suspect that many of your articles would
> simply
>> not be approved by the moderator. Feel free to try to prove me wrong.
>
> As would many of yours.
It's possible, but irrelevant, since I never start these kinds of
disagreement anyway. But, as it happens, although I don't regularly read
clcm, I have had around 90 articles posted there, according to Google.
>> > which you would never hear in the real world.
>>
>> Well, actually, I do discuss such (relevant) technical details in the
>> real world, as well as on Usenet. And anyway, what makes you think that
>> Usenet is not part of the real world?
>
> Stop with the sniveling wordplay already.
Do you always resort to abuse when you run out of logic?
>
>> > Then they
>> > get turned off to C and think it's for wankers.
>>
>> Speculation. I've found that people often respond well to being told the
>> underlying truth, rather than the helicopter-joystick method of
>> programming: "fiddle with the program, and watch what the computer does,
>> because if you want it to do that again, that is the code you have to
>> write" is not a very satisfactory way to learn programming.
>
> I agree that that's a terrible way to learn. Without the concepts, you're
> just blindly hacking.
And that's why we treat the concepts so seriously here, the ones that you
seem so loathe to recognise as important - such as the concept of "object".
> That's why I specifically said that you need at
> least TWO perspectives. I encourage them to read
> your article. My claim is that that's not sufficient.
> They should read a concrete explanation like mine.
> Together they will help you understand pointers.
Specific discussions of particular platforms /are/ sometimes held here, but
they normally demonstrate why concrete experience can be misleading rather
than enlightening.
<snip>
>> [...] The real question was about pointers.
>
> OK, so do you think that the OP wanted just to study pointers for the sake
> of dinner party conversation, or eventually write a real program? Again,
> READ BETWEEN THE LINES.
I think that the OP wanted to study pointers so that he could understand
them. That is why I answered as I did. To derive one's "understanding" of
pointers from a particular platform is a foolish thing to do. There are
still people who think that C has "near" and "far" keywords, and who are
rather surprised when their pointer code suddenly stops working when moved
to a different target machine. They have learned pointers your way. They
should have learned them properly, didn't, and now pay the price.
>> > It may technically, but not in colloquial usage.
>>
>> Then colloquial usage is wrong, and should be changed.
>
> Q.E.D. Another perfect example of why my underemployed flames were so
> accurate.
I do not have such a huge amount of spare time that there is not a cost to
the community associated with my taking time out to debunk your errors.
> Everybody else is wrong; and you're right.
At last you understand.
Simon Biber
> Yes, a typo, already corrected elsethread. No, I didn't notice it myself.
Yes, sorry, the elsethread had not yet reached my news server when I replied.
--
Simon.
Roose
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. : )
"Chris Torek" <nos...@elf.eng.bsdi.com> wrote in message
news:bo4q7k$2ms$1...@elf.eng.bsdi.com...
Alan Connor
>
>
> In article <KDipb.3933$qh2....@newsread4.news.pas.earthlink.net>
> Alan Connor <xx...@yyy.zzz> writes:
>>So memory is just dumb storage. I didn't realize that.
>
> Good, because there are machines on which this is not the case. :-)
>
Wouldn't ya know it...
> C's model (of "objects" and values) does require that plain old
> "dumb storage" memory *exist*, but it permits "smart storage" too,
> and on machines that have it, compilers are allowed to use it.
>
> (There is an important and interesting -- but alas, off-topic in
> c.l.c -- class of machines with "atomic memory" on which various
> forms of lock-free parallelism are possible.)
>
Well, it's incomprehensible and therefore SHOULD be OT :-)
>>On Sun, 02 Nov 2003 21:30:37 GMT, Roose <nos...@nospam.nospam> wrote:
>>>Memory is just a big array of bytes. If you have 1 gig of memory,
>>>pretend it is addressed 0 .. 0x3FFFFFFF. ... 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.
>
> I am not sure which part you "don't get",
90% of this post, as a matter of fact.
Thanks for the effort, but I'm still not exactly sure what an object is.
(except that they aren't 3-dimensional constructions having weight and mass)
Co-processing parallel non-linear 16-bit sugar-free oscillators are a
wee bit over my head...
Alan Connor
>
>
> Roose wrote:
>
>>> I do wonder why K&R didn't find it important enough to include a
>>> reference
>>> to it in the index to the 2nd Edition....
>>
>> Not to be redundant, but this is probably because it is not common in
>> colloquial usage among C programmers.
>
> On the contrary, it's simply a false statement. The term /is/ in the index
> of K&R2.
>
> --
You are right. I was looking at the C Answer Book. Sorry.
But the explanation in K&R is not nearly as good as the ones I received
from you and others here.
Morris Dovey
> Roose wrote:
>
>>> I do wonder why K&R didn't find it important enough to
>>> include a reference to it in the index to the 2nd
>>> Edition....
>>
>> Not to be redundant, but this is probably because it is not
>> common in colloquial usage among C programmers.
>
> On the contrary, it's simply a false statement. The term /is/
> in the index of K&R2.
In my 1978 first edition of K&R, Chapter 0, page 3:
"In C. the fundamental data objects are characters, integers of
several sizes, and floating point numbers. In addition, there is
a heirarchy of derived data types created with pointers, arrays,
structures, unions, and functions."
The term did not appear in the index of K&R1; and one needs to do
a little reading to find it - but only a /little/ since the
quoted text appears at the very top of page three. 8-)
Probably the "C programmers" referred to are those who prefer
ignorance to the drudgery of reading all that boring technical
literature and learning the associated vocabulary - self-styled
'free spirits' and all that (the kind who only check the value
returned from critical functions when they're in the mood.)
--
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.
Richard Heathfield
> Richard Heathfield wrote:
>
>> The term ["object"] /is/ in the index of K&R2.
>
> In my 1978 first edition of K&R, Chapter 0, page 3:
>
> "In C. the fundamental data objects are characters, integers of
> several sizes, and floating point numbers. In addition, there is
> a heirarchy of derived data types created with pointers, arrays,
> structures, unions, and functions."
Parcel the book up carefully. I'll send you my mailing address under
separate cover.
<snip>
> Probably the "C programmers" referred to are those who prefer
> ignorance to the drudgery of reading all that boring technical
> literature and learning the associated vocabulary - self-styled
> 'free spirits' and all that (the kind who only check the value
> returned from critical functions when they're in the mood.)
I'm afraid that this point will be lost on the very people who could learn
most from it, but that doesn't make it any less true.
Irrwahn Grausewitz
> Irrwahn Grausewitz <irrw...@freenet.de> wrote:
> >
<abstRoose's crap snipped>
> > Reread the thread: the poster asked for the definition of the term
> > "object" in the context of the C language. Why not answer his question
> > instead of gibbering?
>
> It wasn't "gibbering", it was very helpful.
If you find misleading, off-topic and partly incorrect information
given by an individual having horrible misconceptions about how C works
helpful: your decision. Just be prepared for others to disagree.
> A lot more helpful than this.
Indeed; why did you post it then?
Regards
--
Irrwahn
(irrw...@freenet.de)
Peter "Firefly" Lund
> Perhaps it wouldn't be a bad idea to learn a little assembly language at
> this point?
It would be a very good idea. Just don't fall into the trap that Roose
does: that all the world looks like the particular cpu you have learnt.
There are many things that seem natural and obvious if all you know is a
typical CPU architecture and a not too smart C compiler. Things which
aren't actually C but only happen to work. Sometimes.
> May I also point out that quoting the ANSI standard to a novice is about
> as useful as replying in Swahili :-)
Telling you fantasy stories that sound right but aren't shouldn't be very
useful, either ;)
-Peter
Being really good at C++ is like being really good at using rocks to
sharpen sticks.
-- Thant Tessman
Roose
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/articles/LeakyAbstractions.html
http://biztech.ericsink.com/Abstraction_Pile.html
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.
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.)
> 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)
2) Constructs like functions, for and while loops, if's and switches, to
organize this enormous stream of instructions
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.
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.
Roose
Thomas Stegen
> 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.
Roose
Ignore the trolls... there's nothing particular about the architecture I
described... other than the numbers, and I already said where those came
from. As I said, what I described is basically a von Neumann machine, which
is something you would learn about in college if you took a course on
computer architecture.
And yes, I do program on wildly different architectures -- PS2, GameCube,
and XBox, each of which have more than one processor and memory space. And
I write code that is portable across the 3 consoles.
"Peter "Firefly" Lund" <fir...@diku.dk> wrote in message
news:Pine.LNX.4.58.03...@ask.diku.dk...
Joona I Palaste
> Alan,
> Ignore the trolls... there's nothing particular about the architecture I
> described... other than the numbers, and I already said where those came
> from. As I said, what I described is basically a von Neumann machine, which
> is something you would learn about in college if you took a course on
> computer architecture.
Would these trolls have names like Heathfield and Grausewitz? In that
case you have a pretty weird definition of "troll".
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge
pete
> 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.
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
Roose
from my posts... otherwise I'm not going to bother responding to your post,
either.
Richard wrote:
> If one wishes to write /correct/ C programs, an understanding of the
> principles laid out in the Standard is vital. The easiest way to achieve
> this understanding is by reading and understanding the C Standard.
What percent of the total number of C programs in the world do you think are
correct in this sense?
Was your first C program correct in this sense? Would it have taken more
time and effort to make it correct, knowing what you knew then? What do you
think the OP is interested in doing, _at this stage in the game_? Do think
he is interested in reading the C standard, before having written anything
substantial or understanding pointers at a practical level?
No sarcasm there, just answer honestly.
"Richard Heathfield" <dont...@address.co.uk.invalid> wrote in message
news:bo4tbr$4m$1...@hercules.btinternet.com...
Richard Heathfield
> 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.
CBFalconer
> On Sun, 2 Nov 2003, Alan Connor wrote:
>
> > Perhaps it wouldn't be a bad idea to learn a little assembly
> > language at this point?
>
> It would be a very good idea. Just don't fall into the trap
> that Roose does: that all the world looks like the particular
> cpu you have learnt.
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".
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.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Joona I Palaste
> 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 once took it upon myself to learn the assembly language of the MOS
Technologies 6502 and 6510 series. This is the only real-world processor
whose assembly language I know. Nevertheless, it has given me an insight
to how assembly languages differ from high-level languages such as C.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I will never display my bum in public again."
- Homer Simpson
Lew Pitcher
>CBFalconer <cbfal...@yahoo.com> scribbled the following:
>> 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 once took it upon myself to learn the assembly language of the MOS
>Technologies 6502 and 6510 series. This is the only real-world processor
>whose assembly language I know. Nevertheless, it has given me an insight
>to how assembly languages differ from high-level languages such as C.
In college, I learned (to my later benefit) IBM 370 Assembly language. Around
the time I got my first real job in computers, I taught myself Intel 8080
Assembly /and/ Zilog Z80 Assembly language. Prior to that, I had a brush with
PDP-10 and PDP-11 assembler language, but never really understood them.
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. ;-)
--
Lew Pitcher
IT Consultant, Enterprise Technology Solutions
Toronto Dominion Bank Financial Group
(Opinions expressed are my own, not my employers')
Alan Connor
What Roose posted was very helpful to me.
I am not going to dismiss an obviously intelligent and learned person on
your say so.
--
Alan C this post ends with w
sq
Alan Connor
>
>
> Alan,
>
> Ignore the trolls... there's nothing particular about the architecture I
> described... other than the numbers, and I already said where those came
> from. As I said, what I described is basically a von Neumann machine, which
> is something you would learn about in college if you took a course on
> computer architecture.
>
> And yes, I do program on wildly different architectures -- PS2, GameCube,
> and XBox, each of which have more than one processor and memory space. And
> I write code that is portable across the 3 consoles.
>
I can tell the wheat from the chaff, Richard.
--
Alan C this post ends with w
q
Alan Connor
>
>
> Peter \"Firefly\" Lund wrote:
>> On Sun, 2 Nov 2003, Alan Connor wrote:
>>
>> > Perhaps it wouldn't be a bad idea to learn a little assembly
>> > language at this point?
>>
>> It would be a very good idea. Just don't fall into the trap
>> that Roose does: that all the world looks like the particular
>> cpu you have learnt.
>
> 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.
> 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.
Thanks much. Actually sounds fascinating.
Alan Connor
Thanks Thomas.
Alan Connor
>
>
> 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"?
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 Connor
>
>
> [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.
Lew Pitcher
>On Mon, 03 Nov 2003 17:12:11 GMT, pete <pfi...@mindspring.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 *PointerToSomething;
you can
PointerToSomething = &SomeThingElse;
but not
PointerToSomething = &SomeThing;
because SomeThing is a register qualified object, but SomeThingElse is not.
Alan Connor
>
>
> 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/articles/LeakyAbstractions.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!
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.
Irrwahn Grausewitz
You call Heathfield a troll? Bwhm. Bwhmhe. Bwhmhehehehe.
Bruahahahahahhaaaahahahahaahaaaaaahhaha <gasp> gnihihihihi.
You haven't been reading c.l.c for more than two days, have you?
--
Irrwahn
(irrw...@freenet.de)
Irrwahn Grausewitz
> 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
(irrw...@freenet.de)
Irrwahn Grausewitz
> On Mon, 03 Nov 2003 18:40:15 GMT, CBFalconer <cbfal...@yahoo.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
(irrw...@freenet.de)
Chris Torek
Roose <nos...@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 (40°39.22'N, 111°50.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.
Morris Dovey
> 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.
Default User
> What Roose posted was very helpful to me.
I'm not sure why you are so fascinated with Roose the Troll, but it's
not a good way to get good information in this newsgroup.
> I am not going to dismiss an obviously intelligent and learned person on
> your say so.
Irrwhan is a knowledgable and helpful member of this group. Roose is a
dispenser of bad information and a troll. I suggest reviewing the two
persons' posting history on this newsgroup via a visit to groups.google.
Brian Rodenborn
Default User
[Richard Heathfield]
> Well, you just crossed the line with that bit of deceitful and sophomoric
> trolling.
You are making a huge mistake. Richard is a frequent posters, a textbook
author and a well-respected member of this newsgroup.
Roose, on the other hand, is a troll who willing dispenses erroneous
information and replies with flames when challenged.
I suggest you reverse your decision. Killfile Roose, do not do the same
with Richard.
Brian Rodenborn
August Derleth
> 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.
> 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? ;)
> 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?
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|decrement] being usefully
different from post[increment|decrement] both came directly from the
PDPs.
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. ;)
Richard Heathfield
> On Mon, 3 Nov 2003 18:20:31 +0000 (UTC), Richard Heathfield
> <dont...@address.co.uk.invalid> 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.
Not a troll, not deceitful. "Sophomoric" is a matter of opinion, of course,
but I can assure you that I am not, nor have I ever been, a sophomore.
> Killfiled for N days.
You have absolutely no idea how devastated I am to hear this.
> I'm into saving time too.
The biggest win is to stop reading Usenet.
CBFalconer
> Alan Connor <zzz...@xxx.yyy> wrote:
>
> >
> >What's a "register (qualified) object"?
>
> register int SomeThing;
>
> as opposed to
>
> int SomeThingElse;
>
> Given
> int *PointerToSomething;
>
> you can
> PointerToSomething = &SomeThingElse;
> but not
> PointerToSomething = &SomeThing;
> because SomeThing is a register qualified object,
> but SomeThingElse is not.
Which doesn't answer his question. The above is a penalty for
using register qualification, which actually means "I think this
variable would be better handled in a register". It is only a
suggestion, and the compiler need not pay any attention to it,
other than to enforce the above penalty. With modern optimizers
it is usually better not used.
CBFalconer
> CBFalconer <cbfal...@yahoo.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.
You have a basic misconception. He may think he is addressing
you, and you may think he is addressing you, but in reality he is
addressing the general public, as are you and I. He may also have
been addressing points you brought up. There is nothing private
about anything said here. Thus the cavils are needed to avoid
misinforming the larger audience.
So far your evaluation of the newsgroup participants appears to be
sadly flawed.
Sheldon Simms
> 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.
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.
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.
Perhaps you think that's just hypothetical, that you'll worry
about the details when you know C better. Well that might work,
but on the other hand, I have seen things like that happen
(well, nothing as dramatic as a plane crash) because the
programmer didn't *really* know how C worked.
-Sheldon
Mark McIntyre
I'm sorry, did you just killfile RJH?
>I'm into saving time too.
well, killfiling the CLC regulars and gurus is certainly going to
achieve that. After a fashion.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Mark McIntyre
>Mark: The limit for sigs on the Usenet is 4 lines and they need to be
>immediately below a "-- " line.
I have no control over what alibis.com stick on after my sig, which is
three lines long.
>Fix yours or I will have to killfile you.
Feel free.
>What Newsfeed.Com is doing amounts to nothing but spam. Ditch them.
Its that or ntl's servers. Believe me, you don't want to use ntl's
news servers for more than about ten seconds.
By the way, are you also known as roose? I'm suspicious of your sudden
appearance in this thread, and your evident agreement with a troll.
Apologies if I'm maligining you but you see my point?
BruceS
"Richard Heathfield" <dont...@address.co.uk.invalid> wrote in message
news:bo6ml9$qif$2...@titan.btinternet.com...
> Alan Connor wrote:
<snip>
> > Well, you just crossed the line with that bit of deceitful and
sophomoric
> > trolling.
>
> Not a troll, not deceitful. "Sophomoric" is a matter of opinion, of
course,
> but I can assure you that I am not, nor have I ever been, a sophomore.
OK, I for one have been getting a good laugh at your exchanges with Roose,
but this bit surprises me. Is it a British thing, or have you really never
been in the second year of secondary school or college? EMWTK.
<snip>