What is an object?

[E. Robert Tisdale]

It's a tangible thing.


Middle English, from Medieval Latin /objectum/.


Not necessarily. In programing, an "object" can refer to virtually anything
(although probably limited to things that occupy memory).
So a struct or even an primative type like an int.
With this definition objects in "object oriented programming"
are no different from C, OOP just associates the functions
that operate on that object with the object.
So you do letter.Write(stream) vs. letter_write(letter, stream).
Of course OOP adds a lot of other fancy stuff that can be useful.

I'm pretty sure that C objects are *not* tangible things
and I don't think that
the definition of object used in the C standards documents
appears anywhere in Medieval Latin.
The C programming language also associates functions (and operators)
with objects of built-in types and allows programmers
to define functions for any User Defined Type (UDT) [struct].

 

[E. Robert Tisdale]

Looking at "An object has state, behavior, and identity;
the structure and behavior of similar objects
are defined in their common class;
the terms instance and object are interchangeable" we can
see that C object does not fit in this set,

there is no behaviour associated as such with C objects.

That's *not* true.
Behavior is *precisely* defined for *all* of the built-in types
and behavior for any User Defined Type (UDT) [struct]
is defined by the programmer.

Types have behavior; that doesn't imply that objects have behavior.

An object (as the term is defined in the C standard, and as I believe
Thomas Stegen was using the term) needn't have a type.

For example:

void *ptr = malloc(42);

The region of data storage to which ptr points (assuming malloc()
returned a non-null result) is an object, but it has no inherent type.

So void is not a type?

 

[E. Robert Tisdale]

there is no behaviour associated as such with C objects.

That's *not* true.
Behavior is *precisely* defined for *all* of the built-in types
and behavior for any User Defined Type (UDT) [struct]
is defined by the programmer.

Nope, in C, the data is applied to operators.
In the above sense, operators (or messages) are applied to data.

Could you please explain the difference?

 

[Niklas Matthies]

I believe that functions are objects in both Python and Java.

In Python perhaps, but not in Java.

-- Niklas Matthies

 

[E. Robert Tisdale]

E. Robert Tisdale writes:
[...]

I believe that functions are objects in both Python and Java.
What, exactly, in the [C standard] definition of object,
disqualifies functions as objects?

A function is not a "region of data storage in the execution
environment, the contents of which can represent values".

Why?

 

[CBFalconer]

.... snip ...

I believe that functions are objects in both Python and Java.
What, exactly, in the [C standard] definition of object,
disqualifies functions as objects?

The wording.

 

[CBFalconer]

Looking at "An object has state, behavior, and identity;
the structure and behavior of similar objects
are defined in their common class;
the terms instance and object are interchangeable" we can
see that C object does not fit in this set,

there is no behaviour associated as such with C objects.

That's *not* true.
Behavior is *precisely* defined for *all* of the built-in types
and behavior for any User Defined Type (UDT) [struct]
is defined by the programmer.

Google for "reading for comprehension"

 

[Martin Ambuhl]

That's *not* true.
Behavior is *precisely* defined for *all* of the built-in types
and behavior for any User Defined Type (UDT) [struct]
is defined by the programmer.

Google for "reading for comprehension"

Trollsdale is trying to convince us of his stupidity. I admit that he
has won me over: he really *is* that stupid.

 

[Keith Thompson]

Keith Thompson wrote: [...]

Types have behavior; that doesn't imply that objects have behavior.
An object (as the term is defined in the C standard, and as I believe
Thomas Stegen was using the term) needn't have a type.
For example:
void *ptr = malloc(42);
The region of data storage to which ptr points (assuming malloc()
returned a non-null result) is an object, but it has no inherent type.

So void is not a type?

void is a type. More specifically, void is an incomplete type.

void is not an object type. The object to which ptr points is not an
object of type void, because there is no such thing.

 

[Keith Thompson]

Keith Thompson wrote: [...]

Types have behavior; that doesn't imply that objects have behavior.
An object (as the term is defined in the C standard, and as I believe
Thomas Stegen was using the term) needn't have a type.
For example:
void *ptr = malloc(42);
The region of data storage to which ptr points (assuming malloc()
returned a non-null result) is an object, but it has no inherent type.

So void is not a type?

void is a type. More specifically, void is an incomplete type.

void is not an object type. The object to which ptr points is not an
object of type void, because there is no such thing.

I see I was slightly ambiguous. I meant that there is no such thing
as an object of type void. (It could be interpreted to mean that
there is no such thing as the object to which ptr points; in fact,
there is such an object.)

 

[Eric Schmidt]

Thomas Stegen wrote:

Looking at "An object has state, behavior, and identity;
the structure and behavior of similar objects
are defined in their common class;
the terms instance and object are interchangeable" we can
see that C object does not fit in this set,
there is no behaviour associated as such with C objects.

That's *not* true.
Behavior is *precisely* defined for *all* of the built-in types
and behavior for any User Defined Type (UDT) [struct]
is defined by the programmer.

Types have behavior; that doesn't imply that objects have behavior.

An object (as the term is defined in the C standard, and as I believe
Thomas Stegen was using the term) needn't have a type.

For example:

void *ptr = malloc(42);

The region of data storage to which ptr points (assuming malloc()
returned a non-null result) is an object, but it has no inherent type.

So void is not a type?

It's an incomplete type. An object cannot have an incomplete type.

 

[E. Robert Tisdale]

Thomas Stegen wrote:


Looking at "An object has state, behavior, and identity;
the structure and behavior of similar objects
are defined in their common class;
the terms instance and object are interchangeable" we can
see that C object does not fit in this set,


there is no behaviour associated as such with C objects.

That's *not* true.
Behavior is *precisely* defined for *all* of the built-in types
and behavior for any User Defined Type (UDT) [struct]
is defined by the programmer.


Types have behavior; that doesn't imply that objects have behavior.

An object (as the term is defined in the C standard, and as I believe
Thomas Stegen was using the term) needn't have a type.

For example:

void *ptr = malloc(42);

The region of data storage to which ptr points (assuming malloc()
returned a non-null result) is an object, but it has no inherent type.

So void is not a type?

It's an incomplete type. An object cannot have an incomplete type.

So ptr is *not* a pointer to an object in the example above?

 

[Jack Klein]

But isn't a function pointer an object? Doesn't a function name resolve into
a function pointer the same way an array name resolves into an array
pointer? Is "resolve" a word?

Yes, a function pointer is an object, just as a pointer to char is an
object. A pointer to void or any data type can hold an address, but
an address itself is an 'rvalue' and not an object. Just as any
integer is an object and can hold the value 1, but the value 1 itself
is an 'rvalue' and not an object. Furthermore scalar objects can only
hold values (or trap representations). A function pointer is a scalar
object.

I put 'quotes' around the term 'rvalue' because it is no longer a
defined term in C99.

So a function pointer is an object that can hold values. The type of
values that a function pointer can store are 'function designators':

========
6.3.2.1 Lvalues, arrays, and function designators

[snip]

4 A function designator is an expression that has function type.
Except when it is the operand of the sizeof operator or the unary &
operator, a function designator with type ‘‘function returning type’’
is converted to an expression that has type ‘‘pointer to function
returning type’’.
========

So the function designator itself is converted to an 'rvalue' of type
pointer to function, which can be used either to call the function or
assign it to an object of type pointer to function. But the function
designator itself is not an object.

 

[E. Robert Tisdale]

But isn't a function pointer an object?
Doesn't a function name resolve into a function pointer
the same way an array name resolves into an array pointer?
Is "resolve" a word?

Yes, a function pointer is an object,
just as a pointer to char is an object.
A pointer to void or any data type can hold an address,
but an address itself is an 'rvalue' and not an object.
Just as any integer is an object and can hold the value 1,
but the value 1 itself is an 'rvalue' and not an object. Furthermore,
scalar objects can only hold values (or trap representations).
A function pointer is a scalar object.

I put 'quotes' around the term 'rvalue'
because it is no longer a defined term in C99.

So a function pointer is an object that can hold values. The type of
values that a function pointer can store are 'function designators':

========
6.3.2.1 Lvalues, arrays, and function designators

[snip]

4 A function designator is an expression that has function type.
Except when it is the operand of the sizeof operator or the unary &
operator, a function designator with type ‘‘function returning type’’
is converted to an expression that has type ‘‘pointer to function
returning type’’.
========

So the function designator itself is converted to an 'rvalue' of type
pointer to function, which can be used either to call the function or
assign it to an object of type pointer to function.
But the function designator itself is not an object.

Can you tell us *why* a function is not an object?

Are you telling us that a function is *not* an object
because you can't assign a value to it?
Because it isn't an 'lvalue"?
Or because a function isn't data?

Exactly what is it in the definition of an object
that disqualifies functions as objects?

 

[Douglas A. Gwyn]

Why?

Because that's the way it actually is, historically
(witness cc -i on the PDP-11), and we want to
continue to encourage that practice.

 

[Douglas A. Gwyn]

So void is not a type?

That's not what he said nor implied.

 

[Douglas A. Gwyn]

The C programming language also associates functions (and operators)
with objects of built-in types and allows programmers
to define functions for any User Defined Type (UDT) [struct].

Wrong.

 

[Douglas A. Gwyn]

What do you mean by type?

Read the C standard.

How is a C type different from an Abstract Data Type (ADT):
1.) the set of values that an object can have
together with
2.) all of the methods that can be applied
to an object of that type.

For one thing, there are no methods associated with
a C data type.

Does a C type depend upon its representation?

That is a confused question.

Is data abstraction possible in C?

Yes.

 

[RCollins]

The C programming language also associates functions (and operators)
with objects of built-in types and allows programmers
to define functions for any User Defined Type (UDT) [struct].

Wrong.

What's wrong with what he said? It seems to me that the operators
(+, -, *, etc) are associated by the compiler with numerical objects.
And, I can certainly write my own structs, and functions that operate
on those structs in whatever manner I choose.

So, what *exactly* did ERT say that was wrong?

 

[RCollins]

Keith Thompson wrote:



Thomas Stegen wrote:


Looking at "An object has state, behavior, and identity; the
structure and behavior of similar objects are defined in their
common class; the terms instance and object are interchangeable"
we can
see that C object does not fit in this set,




there is no behaviour associated as such with C objects.


That's *not* true.
Behavior is *precisely* defined for *all* of the built-in types
and behavior for any User Defined Type (UDT) [struct]
is defined by the programmer.



Types have behavior; that doesn't imply that objects have behavior.

An object (as the term is defined in the C standard, and as I believe
Thomas Stegen was using the term) needn't have a type.

For example:

void *ptr = malloc(42);

The region of data storage to which ptr points (assuming malloc()
returned a non-null result) is an object, but it has no inherent type.


So void is not a type?

It's an incomplete type. An object cannot have an incomplete type.

So ptr is *not* a pointer to an object in the example above?

In everyday use, "ptr" is a pointer to a block of memory; but until
that memory has had some sort of structure applied to it, I don't
think we can safely call it an "object". (It may, infact, be 42
objects).