Hey guys, I'm new here, just a simple question.
I'm learning to Program in C, and I was recommended a book called,
"Mastering C Pointers", just asking if any of you have read it,
and if it's worth the $25USD.
I'm just looking for a book on Pointers, because from what I've
read it's one of the toughest topics to understand.
thanks in advanced.
sincerely ... Andy
388  21368 
On Sat, 01 Nov 2003 12:51:44 -0500, 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'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.
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.
-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.
thanks, I just wanted some advice, thats all.
I appreciate your help.
Try "Pointers on C", that's not a bad book, and covers pointers fairly well.
It has a lot of basic C stuff too.
"Andy" <ma******@bellsouth.net> wrote in message
news:YK*****************@bignews5.bellsouth.net... -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.
thanks, I just wanted some advice, thats all.
I appreciate your help.
maniac <ma******@bellsouth.net> wrote in message news:<9o****************@bignews4.bellsouth.net>.. . Hey guys, I'm new here, just a simple question.
I'm learning to Program in C, and I was recommended a book called,
"Mastering C Pointers", just asking if any of you have read it,
and if it's worth the $25USD.
I'm just looking for a book on Pointers, because from what I've
read it's one of the toughest topics to understand.
thanks in advanced.
sincerely ... Andy
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
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.
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.
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.
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 : bi****@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 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.
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.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer wrote: 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 : bi****@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
Richard Heathfield wrote: 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.
--
Richard Heathfield : bi****@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
On Sun, 2 Nov 2003 06:22:40 +0000 (UTC), Richard Heathfield <do******@address.co.uk.invalid> wrote:
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
"Alan Connor" <zz****@xxx.yyy> wrote in message
Would you mind defining "object" for a shell scripter just starting to
learn C?
The problem is that "object" has one meaning in object-oriented programming,
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.
In C, there is no technical term "object", but he means anything which
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. 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
Alan Connor <zz****@xxx.yyy> wrote: 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
(ir*******@freenet.de)
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;
--
Richard Heathfield : bi****@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
Roose wrote: 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.
--
Richard Heathfield : bi****@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
I know you still hold a grudge for being so thoroughly embarassed, but give
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...)
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.
The grudge seems to be on your side FWIW.
--
Thomas.
"Roose" <no****@nospam.nospam> wrote:
[top-posting and quoting fixed] Alan Connor <zz****@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
(ir*******@freenet.de)
"Roose" <no****@nospam.nospam> wrote:
<snip> I'm trying to help the guy learn.
This is best done by providing *correct* information.
--
Irrwahn
(ir*******@freenet.de)
Roose wrote: 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>
--
Richard Heathfield : bi****@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
"Richard Heathfield" <do******@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.
[...]
That's it. Pointers are really that simple.
Perhaps not. :-)
--
Simon.
Simon Biber wrote: "Richard Heathfield" <do******@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. :-)
--
Richard Heathfield : bi****@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
Thomas Stegen wrote: 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.
The grudge seems to be on your side FWIW.
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
"Andy" <ma******@bellsouth.net> wrote in message
news:pt*****************@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.
Roose <no****@nospam.nospam> scribbled the following: "Andy" <ma******@bellsouth.net> wrote in message
news:pt*****************@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 (pa*****@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
"Thomas Stegen" <ts*****@cis.strath.ac.uk> wrote in message
news:3f********@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.
"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message
news:r1********************************@4ax.com... "Roose" <no****@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.
> > 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. 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
I meant "C" of course, not "C++". I know it's hard with such a literal mind
to read between the lines. 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 (pa*****@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 <no****@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.
Second, a literal mind is pretty much a requirement on comp.lang.c.
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"My absolute aspect is probably..."
- Mato Valtonen
> > 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.
..."insular little world of the C standard as a bible" ...
Damn I keep hearing echoes of my earlier posts again...
<stuff not related to the definition of objects in C snipped>
--
Irrwahn
(ir*******@freenet.de)
"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bo**********@oravannahka.helsinki.fi... Roose <no****@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 Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"My absolute aspect is probably..."
- Mato Valtonen
Roose <no****@nospam.nospam> scribbled the following: "Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bo**********@oravannahka.helsinki.fi... Roose <no****@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 (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Hasta la Vista, Abie!"
- Bart Simpson
On Sun, 2 Nov 2003 11:03:04 +0000 (UTC), Richard Heathfield <do******@address.co.uk.invalid> wrote:
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.
--
Alan C this post ends with w
q
On Sun, 02 Nov 2003 20:46:18 GMT, in comp.lang.c , "Roose"
<no****@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 =---
On Sun, 02 Nov 2003 13:59:19 -0500, in comp.lang.c , Andy
<ma******@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
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 =---
On Sun, 02 Nov 2003 20:43:30 GMT, in comp.lang.c , "Roose"
<no****@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.
--
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 =---
> 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. 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
Roose wrote: > 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.
<snip>
--
Richard Heathfield : bi****@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
Alan Connor wrote: 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.
--
Richard Heathfield : bi****@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
"Roose" <no****@nospam.nospam> wrote in message
news:ra**************@newssvr27.news.prodigy.com.. . In C, there is no technical term "object", [snip]
Please don't top-post.
"Roose" <no****@nospam.nospam> wrote in message
news:S2****************@newssvr27.news.prodigy.com ... I know you still hold a grudge [crap snipped]
Please don't top-post.
"Roose" <no****@nospam.nospam> wrote in message
news:YX****************@newssvr27.news.prodigy.com ... I meant "C" of course, not "C++". [crap "of course" snipped]
Please don't top-post.
On Sun, 02 Nov 2003 02:35:30 -0500
Andy <ma******@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.
"Roose" <no****@nospam.nospam> wrote: "Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message
news:r1********************************@4ax.com... "Roose" <no****@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
(ir*******@freenet.de)
"Roose" <no****@nospam.nospam> wrote:
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
(ir*******@freenet.de) This thread has been closed and replies have been disabled. Please start a new discussion. |
