difference

[Ramkumar R K]

what is the difference between objects and pointers?

[pete]

Joe Wright wrote:

Is a + b an object?

Another way of looking at it, is that a + b isn't an identifier.
If you don't have an identifier and you don't have an address,
then what object would you be talking about?

I only know three ways to create objects in a program.
1 Declared variables are objects.
2 String literals refer to anonymous objects,
when the string literals aren't array initializers.
3 A non NULL return value from malloc or friends, is
a pointer to an anonymous object.

--
pete

[pete]

E. Robert Tisdale wrote:

For the definition of the term object,
you should consult an English language dictionary:

Only if you're not discussing C.
Using a Standard English dictionary to get the defintition of words,
which are technical terms, defined in the C standard, is ...

WHAT THE HELL IS WRONG WITH YOU ?!!!

--
pete

[Joe Wright]

Hallvard B Furuseth wrote:

Joe Wright wrote:

Hallvard B Furuseth wrote:

I think integer constants are objects, and that what this text refers
to is lvalues like *p where p points to freed memory. That freed
memory is no longer an object.

From K&R2 A4 p195
"An object, sometimes called a variable, is a location in storage, and
its interpretation depends on two main attributes: its 'storage class'
and its 'type'."..

That doesn't sound like a constant to me. I must have missed something
important earlier.

What you missed is that C is defined by the C standard, not by K&R2.
The sentence you quoted illustrates why: It is wrong. It says that all
objects are variables. So malloced memory, which is not a variable, is
not an object.

Give me an example of an integer constant that you
think is an object. Please.

1

Not the way I read it. That the constant 1 has object type (int) does
not make it an object. Its object type describes the object which might
hold the value if you wanted to store it somewhere or the
promotion/conversion rules to apply if you want to do arithmetic with
it. It is not a object.
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Joe Wright]

pete wrote:

Joe Wright wrote:

Is a + b an object?

Another way of looking at it, is that a + b isn't an identifier.
If you don't have an identifier and you don't have an address,
then what object would you be talking about?

I only know three ways to create objects in a program.
1 Declared variables are objects.
2 String literals refer to anonymous objects,
when the string literals aren't array initializers.
3 A non NULL return value from malloc or friends, is
a pointer to an anonymous object.

Thanks pete. It seems you are on the side of reason (my side). There is
some wording in the standard about constants having object type. They
do. I fear this is being construed to mean that constants are objects.
They are not!
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Richard Bos]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

pete wrote:

Joe Wright wrote:

> c = a + b;

Is a + b an object?

Yes.

No. RTBS.

Richard

[Richard Bos]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

Joe Wright wrote:

That doesn't sound like a constant to me.
I must have missed something important earlier.
Give me an example of an integer constant that you think is an object.

For the definition of the term object,
you should consult an English language dictionary:

http://www.bartleby.com/61/

Of course. And integers must be able to split in the middle to produce
smaller integers, and two long doubles should have sex together,
resulting in a cute little float nine nano-months later. Because, after
all, that is the dictionary meaning of "multiplication".

Richard

[pete]

Joe Wright wrote:

pete wrote:

Joe Wright wrote:

Is a + b an object?
Another way of looking at it, is that a + b isn't an identifier.
If you don't have an identifier and you don't have an address,
then what object would you be talking about?

I only know three ways to create objects in a program.
1 Declared variables are objects.
2 String literals refer to anonymous objects,
when the string literals aren't array initializers.
3 A non NULL return value from malloc or friends, is
a pointer to an anonymous object.

Thanks pete. It seems you are on the side of reason (my side).
There is some wording in the standard about
constants having object type. They do.

They do.
I fear this is being construed to mean that constants are objects.
They are not!

They are not.

Here's that in a nutshell:
N869 6.3.2 Other operands
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

(5) is is an expression with an object type
or an incomplete type other than void.

x = (5);

If (5) does not designate an object when it is evaluated,
the behavior is undefined.

From previous discussion on comp.std.c,
I've been informed that what they meant by
"if an lvalue does not designate an object when it is evaluated"
was, an invalidly dereferenced pointer.

char object;
char* pointer;

pointer = &object;
*(pointer + 17) = 0;

The left operand of the last above assignment,
is an example of what they meant by
"an lvalue does not designate an object when it is evaluated".

--
pete

[Hallvard B Furuseth]

Joe Wright wrote:

pete wrote:

Joe Wright wrote:

Is a + b an object?
Another way of looking at it, is that a + b isn't an identifier.
What of it?
If you don't have an identifier and you don't have an address,
then what object would you be talking about?

An unnamed object, of course. Or what is sometimes called a temporary
variable, depending on who you are speaking to.
There is
some wording in the standard about constants having object type. They
do. I fear this is being construed to mean that constants are objects.

Not by me. I've simply assuming that the text from the standard which
Pete claimed is in error in message <40***********@mindspring.com>, is
in fact not on error. The rest follows.

It fits how I think of program execution, anyway. A (sub)expression is
evaluated. The result is a (temporary) object. That object may be
stuffed into a variable by an assignment operator, or whatever. And
the compiler may optimize away the temporary object.

Though I think I should have said that constants, when evaluated,
_become_ objects. I do agree that this does become murky one way or
another. Now that I think of it, it doesn't fit static initializers.
Then only the initialized element is an object.

--
Hallvard

[Hallvard B Furuseth]

pete wrote:

N869 6.3.2 Other operands
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void; if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.

(5) is is an expression with an object type
or an incomplete type other than void.

x = (5);

If (5) does not designate an object when it is evaluated,
the behavior is undefined.

From previous discussion on comp.std.c,
I've been informed that what they meant by
"if an lvalue does not designate an object when it is evaluated"
was, an invalidly dereferenced pointer.

Yes, that's what I thought.

--
Hallvard

[pete]

Hallvard B Furuseth wrote:

Joe Wright wrote:

pete wrote:

Joe Wright wrote:

Is a + b an object?

Another way of looking at it, is that a + b isn't an identifier.
What of it?
If you don't have an identifier and you don't have an address,
then what object would you be talking about?

An unnamed object, of course.

That's not what an unnamed object is.
An unnamed object has an address.
All objects have either an address or an identifier or both.
a + b has neither.
Or what is sometimes called a temporary
variable, depending on who you are speaking to.

Unnamed objects have specified duration and representation
described by the standard.
Temporary variables are not described by the standard
and have nothing to do with C.

For
c = a + b;
the standard doesn't say that the value of a + b will be stored
anywhere else, except in c.

--
pete