difference

[pete]

Is a + b an object?

Suppose that a and b are long and larger than int.
It's possible that the value of a + b might computed in parts,
and the representation, constructed in place, in c.
There is just no implication in the code,
that any long type representation of (a + b) ever exists in
memory prior to being in c.
The entire meaning of the statement, is that after the assignment,
c will have the value of (a + b). It doesn't mean anything else.

 

[E. Robert Tisdale]

Yes.

Suppose that a and b are long and larger than int.
It's possible that the value of a + b might computed in parts,
and the representation, constructed in place, in c.
There is just no implication in the code,
that any long type representation of (a + b) ever exists
in memory prior to being in c.
The entire meaning of the statement is that,
after the assignment,
c will have the value of (a + b).
It doesn't mean anything else.

Consider

int f(void) {
int a = 4;
int b = 5;
int c = a + b;
int d = 6;
int e = c + d;
return e;
}

Does object c actually exist
if your C compiler optimizes away storage for c and evaluates

int e = a + b + d;

directly? Of course it does.

 

[Martin Dickopp]

Consider

int f(void) {
int a = 4;
int b = 5;
int c = a + b;
int d = 6;
int e = c + d;
return e;
}

Does object c actually exist
if your C compiler optimizes away storage for c and evaluates

int e = a + b + d;

directly? Of course it does.

It certainly does in the abstract machine.

Martin

 

[Irrwahn Grausewitz]

I think integer constants are objects,

I don't have enough hard evidence in either direction to answer
the question if integer constants /are/ objects. But: even /if/
they are objects, you can only access the values, but you cannot
locate the objects in memory: an integer constant does not
/designate/ an object. Thus, while integer constants may well
qualify as lvalues (since they are "expressions with object type
[...] other than void"), any attempt to access an object through
them is (at least) a constraint violation or invokes undefined
behaviour (see the references in my previous post).

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.

If p is a dangling pointer, the behaviour of the unary *
operator is undefined in the first place: you won't make it
to the point in time where it matters if the result of evaluating
the expression *p is a valid lvalue at all: the evaluation itself
is undefined. While the case would of course be covered by C99
6.3.2.1, it is explicitly addressed in C99 6.5.3.2#4 anyway.

Regards

 

[pete]

optimizes

I wasn't talking about optimization.
I was talking about the semantics of
the code on the abstract machine.

 

[Hallvard B Furuseth]

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

 

[Hallvard B Furuseth]

My understanding of lvalues and objects is from C89.
If you want to talk C99,
then I just don't know about those things anymore.

I meant the statement you quoted from C89.

 

[pete]

I meant the statement you quoted from C89.

I haven't quoted C89 yet.

C89 last public draft:
3.2.2.1 Lvalues and function designators
An lvalue is an expression (with an object type or an incomplete
type other than void) that designates an object.

In C99, when they say
"if an lvalue does not designate an object when it is evaluated,
the behavior is undefined."
.... they're talking about something like
char *pointer = NULL;
*pointer;

They felt that was more complete than what C89 said.

 

[E. Robert Tisdale]

Hallvard B Furuseth wrote:

[ snip ]

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.
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/

Brian W. Kernighan and Dennis M. Ritchie weren't trying
to define an object in the "object oriented" sense.
That is still an *unfinished* task which you should ask about
in the comp.object newsgroup if you are interested.

I think that it is safe to assume that Kernighan and Ritchie
meant both constants and variables here --
constants must be *initialized* after all.

What is clear from the K&R definition is that
objects are *data* objects
in the context of the C programming language.
They occupy (or, at least, could occupy)
some sort of memory storage -- registers, virtual memory, etc.
They were not talking about so-called real world objects.

Whether data objects exist or not may be irrelevant
if there is no way to reference them in the current scope.

 

[Richard Heathfield]

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

Not in comp.lang.c, you don't.

The ISO C Standard defines the term for the purposes of C; where the C
language is the subject of discussion, this local definition overrides any
wider definition.

(I don't expect Tisdale to understand this, given his track record.)

 

[pete]

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]

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

 

[Joe Wright]

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.


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]

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!

 

[Richard Bos]

Yes.

No. RTBS.

Richard

 

[Richard Bos]

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]

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".

 

[Hallvard B Furuseth]

What of it?

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 <[email protected]>, 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 B Furuseth]

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.

 

[pete]

What of it?


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.