"Mastering C Pointers"....

[Irrwahn Grausewitz]

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 Grausewitz]

I'm trying to help the guy learn.

This is best done by providing *correct* information.

 

[Richard Heathfield]

I know you still hold a grudge
Wrong.

for being so thoroughly embarassed,

Wrong.

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.

 

[Richard Heathfield]

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]

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

 

[Roose]

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]

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.

 

[Joona I Palaste]

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 ([email protected]) ------------- 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]

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]

Fine I was wrong about the term object. Having worked as a professional
C

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.

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.

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]

I meant "C" of course, not "C++". I know it's hard with such a literal mind
to read between the lines.

 

[Joona I Palaste]

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.

 

[Roose]

or data (a simple int, char; an array; a struct or union; a

^^^^^^^^^^^^^^^^^^^
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]

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]

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.

 

[Alan Connor]

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.


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]

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]

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]

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.