What is an object?

[E. Robert Tisdale]

What is an object?
Where did this term come from?
Does it have any relation
to the objects in "object oriented programming"?

 

[Claudio Carobolante]

What is an object?

An object is a region of data storage in the execution environment, the
contents of which can represent values. An object has a type.

Where did this term come from?

ISO/IEC 9899:1999 - 3.14

Does it have any relation
to the objects in "object oriented programming"?

No.

cc

 

[Douglas A. Gwyn]

What is an object?

That depends on the context. The C standard defines
(for *its* purposes) an object as a "region of data
storage in the execution environment, the contents
of which can represent values".

Note that values can also be represented in ways not
associated with any specific data storage, as in fast
registers. Note also that the interpretation of the
contents of an object as some value depends on the
*type* used to access the object, and that some bit
patterns might not be valid representations for any
vale of a specific type. Finally, note that functions
are not objects, and their instruction sequences might
even reside in a totally separate address space.

Where did this term come from?

English language. An object is a concrete "thing".

Does it have any relation
to the objects in "object oriented programming"?

There is a relationship, but not a strong one.
OOP "objects" are associated with "methods" but C
objects are not.

 

[Michael B Allen]

What is an object?

It's a tangible thing.

Where did this term come from?

Middle English, from Medieval Latin /objectum/.

Does it have any relation
to the objects in "object oriented programming"?

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.

Mike

 

[Thomas Stegen]

What is an object?
Where did this term come from?
Does it have any relation
to the objects in "object oriented programming"?

From the comp.object faq (Which you should perhaps have
checked first, it is the very first question):

"1.1) What Is An Object?
-----------------------

There are many definitions of an object, such as found in
[Booch 91, p77]: "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". This
is a "classical languages" definition, as defined in [Coplien 92, p280],
where "classes play a central role in the object model", since they do
not in prototyping/delegation languages. "The term object was first
formally applied in the Simula language, and objects typically existed
in Simula programs to simulate some aspect of reality" [Booch 91, p77].
Other definitions referenced by Booch include Smith and Tockey: "an
object represents an individual, identifiable item, unit, or entity,
either real or abstract, with a well-defined role in the problem
domain." and [Cox 91]: "anything with a crisply defined boundary"
(in context, this is "outside the computer domain"..."

(It is a very good faq and worth reading.)

From the C standard:

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

So at least from a C perspective it seems pretty clear. In OO languages
it is a bit murky, but still we can usually glean useful information
depending on the exact context we are using. It seems that C objects
at least overlap with the OO definition "anything with a crisply defined
boundary".

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.

The comp.object faq also seems to answer your etymology question,
the term object was first formally used in a programming context in the
Simula language. It was probably not the very first time though,
but it gives you a clue on where to start (or not).

 

[Mabden]

That depends on the context. The C standard defines
(for *its* purposes) an object as a "region of data
storage in the execution environment, the contents
of which can represent values".

Note that values can also be represented in ways not
associated with any specific data storage, as in fast
registers. Note also that the interpretation of the
contents of an object as some value depends on the
*type* used to access the object, and that some bit
patterns might not be valid representations for any
vale of a specific type. Finally, note that functions
are not objects, and their instruction sequences might
even reside in a totally separate address space.

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?

 

[James Kuyper]

Mabden wrote:
....

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?

There's an ambiguity here that complicates the discussion. "pointer" is
often used as a short version of either "pointer value" or "pointer
object". A pointer value can be stored in a pointer object, but if p is
a pointer object, then p+1 is a pointer value that is not stored in any
object: &(p+1) is meaningless (and therefore not allowed). A function
name does resolve in certain contexts into a pointer value, which can be
used to call the function, or stored in a pointer object. Similarly, an
array name resolves in certain contexts into a pointer value pointing at
the first element of the array, which can be stored in a pointer object.
However, in both cases the pointer value is not itself an object.

 

[Malcolm]

What is an object?

In C, an entity with contiguous storage that can be represented by a single
identifier, or an array of such entities.
In general computing terms, data items with a close relationship to each
other that it makes sense to regard as being part of the same entity.

Where did this term come from?

Not sure when "object" was first used in computing terms. The important date
is the use of "object-oriented".

"The object-oriented programming paradigm first took root in Simula 67, a
language designed for making simulations, created by Ole-Johan Dahl and
Kristen Nygaard of the Norwegian Computing Centre in Oslo. (Reportedly, the
story is that they were working on ship simulations, and were confounded by
the combinatorial explosion of how the different attributes from different
ships could affect one another. The idea occurred to group the different
types of ships into different classes of objects, each class of objects
being responsible for defining its own data and behavior.) "
http://encyclopedia.thefreedictionary.com/object-oriented programming

Does it have any relation to the objects in "object oriented programming"?

Yes. C compilers on machines without floating point units have floating
point "objects" which suport the basic arithmetical operations. C FILEs are
also "objects" which represent a stream. Object-oriented programming takes
this idea and extends it, by making object user-definable and allowign them
to have more relations with each other.
In a high-level language, however, there is no need for an "object" to have
contiguous storage. This is something that only low-level languages are
concerned with.

 

[Keith Thompson]

Yes. C compilers on machines without floating point units have floating
point "objects" which suport the basic arithmetical operations. C FILEs are
also "objects" which represent a stream. Object-oriented programming takes
this idea and extends it, by making object user-definable and allowign them
to have more relations with each other.
In a high-level language, however, there is no need for an "object" to have
contiguous storage. This is something that only low-level languages are
concerned with.

There is no need for an "object" in the sense of "object-oriented
programming" to have contiguous storage.

An "object" in the sense defined in the C standard does have
contiguous storage (and doesn't necessarily have a type). (At least
I'm assuming that "region of data storage" implies contiguity; if it's
not contiguous, I'd think of it as two or more "regions".)

 

[Eric Sosman]

An "object" in the sense defined in the C standard does have
contiguous storage (and doesn't necessarily have a type). [...]

The word "necessarily" can be deleted. A C object is
simply and only a region of data storage, and has no type.
The expressions that inspect and manipulate the object have
types, and their types govern the interpretation of the bits
that reside in the object, but the object itself is typeless.
One way to think of this is to consider the object not as
holding a value, but as holding a representation -- a typed
expression then derives a value from the representation.

A not-infrequent question is "My function receives a
`void*' argument; how can I discover the type of the thing
it points to?" The response "You can't" often explains that
C's types are a compile-time concept and do not survive into
run-time. Well, the flip-side of that observation is that
since objects are run-time constructs that don't exist at
compile time, they cannot have types! Compile-time types
disappear before any run-time objects are created. (An
interpreter that mingles compilation and execution could
retain some knowledge of type at run-time, but the language
is defined so as not to require such an environment).

C is not alone in the way it separates type from data,
but neither is it true that all languages do so, or do so
in the same way. Lisp, for example, takes the opposite
tack: Lisp's objects have types, while its "expressions"
are typeless. Java takes an intermediate course: all the
objects have types, but so do the expressions (and there
are some forms of data that aren't "objects" in Java's
lexicon).

C's strict separation of type from data has benefits
and drawbacks. The storage model can be quite simple (in
a way, the separation is what makes malloc() possible) and
"reinterpretation" of an object's bits is possible with due
care. On the other hand, some types of run-time errors are
very difficult to detect automatically, and abuses of the
"reinterpretation" license abound. You pays your money and
you takes your choice -- and if your choice is C, you've
chosen to have no types at run-time.

 

[Niklas Matthies]

An "object" in the sense defined in the C standard does have
contiguous storage (and doesn't necessarily have a type). [...]

The word "necessarily" can be deleted. A C object is
simply and only a region of data storage, and has no type.
The expressions that inspect and manipulate the object have
types, and their types govern the interpretation of the bits
that reside in the object, but the object itself is typeless.

That's not quite correct. Objects do have a so-called effective type.
See C99 6.5p6-7:

The /effective type/ of an object for an access to its stored value
is the declared type of the object, if any.72) If a value is stored
into an object having no declared type through an lvalue having a
type that is not a character type, then the type of the lvalue
becomes the effective type of the object for that access and for
subsequent accesses that do not modify the stored value. If a value
is copied into an object having no declared type using memcpy or
memmove, or is copied as an array of character type, then the
effective type of the modified object for that access and for
subsequent accesses that do not modify the value is the effective
type of the object from which the value is copied, if it has one.
For all other accesses to an object having no declared type, the
effective type of the object is simply the type of the lvalue used
for the access.

Footnote: 72) Allocated objects have no declared type.

An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:73)
- a type compatible with the effective type of the object,
- a qualified version of a type compatible with the effective type
of the object,
- a type that is the signed or unsigned type corresponding to the
effective type of the object,
- a type that is the signed or unsigned type corresponding to a
qualified version of the effective type of the object,
- an aggregate or union type that includes one of the
aforementioned types among its members (including, recursively,
a member of a subaggregate or contained union), or
- a character type.

73) The intent of this list is to specify those circumstances in
which an object may or may not be aliased.

-- Niklas Matthies

 

[Douglas A. Gwyn]

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?

Function pointers can be stored in objects, yes.
So what? The *instruction sequences* that implement
the bodies of functions are not required to be
stored in (data) objects.

"Resolve" is a word.

 

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

 

[E. Robert Tisdale]

Mabden wrote:
...

There's an ambiguity here that complicates the discussion.
"pointer" is often used as a short version of either "pointer value"
or "pointer object". A pointer value can be stored in a pointer object
but, if p is a pointer object,
then p+1 is a pointer value that is not stored in any object:
&(p+1) is meaningless (and therefore not allowed).
A function name does resolve in certain contexts into a pointer value,
which can be used to call the function, or stored in a pointer object.
Similarly, an array name resolves in certain contexts into a pointer value
pointing at the first element of the array,
which can be stored in a pointer object.
However, in both cases the pointer value is not itself an object.

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

 

[E. Robert Tisdale]

In C, an entity with contiguous storage that can be represented by a single
identifier, or an array of such entities.
In general computing terms, data items with a close relationship to each
other that it makes sense to regard as being part of the same entity.


Not sure when "object" was first used in computing terms.
The important date is the use of "object-oriented".

The term "object-oriented" was coined by Alan Kay (in 1967?)

http://userpage.fu-berlin.de/~ram/pub/pub_kfd8tk88g/doc_kay_oop_en

 

[E. Robert Tisdale]

An "object" in the sense defined in the C standard does have
contiguous storage (and doesn't necessarily have a type). [...]

The word "necessarily" can be deleted. A C object is
simply and only a region of data storage, and has no type.
The expressions that inspect and manipulate the object have
types, and their types govern the interpretation of the bits
that reside in the object, but the object itself is typeless.

That's not quite correct. Objects do have a so-called effective type.
See C99 6.5p6-7:

The /effective type/ of an object for an access to its stored value
is the declared type of the object, if any.72) If a value is stored
into an object having no declared type through an lvalue having a
type that is not a character type, then the type of the lvalue
becomes the effective type of the object for that access and for
subsequent accesses that do not modify the stored value. If a value
is copied into an object having no declared type using memcpy or
memmove, or is copied as an array of character type, then the
effective type of the modified object for that access and for
subsequent accesses that do not modify the value is the effective
type of the object from which the value is copied, if it has one.
For all other accesses to an object having no declared type, the
effective type of the object is simply the type of the lvalue used
for the access.

Footnote: 72) Allocated objects have no declared type.

An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:73)
- a type compatible with the effective type of the object,
- a qualified version of a type compatible with the effective type
of the object,
- a type that is the signed or unsigned type corresponding to the
effective type of the object,
- a type that is the signed or unsigned type corresponding to a
qualified version of the effective type of the object,
- an aggregate or union type that includes one of the
aforementioned types among its members (including, recursively,
a member of a subaggregate or contained union), or
- a character type.

73) The intent of this list is to specify those circumstances in
which an object may or may not be aliased.

What do you mean by type?

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.

Does a C type depend upon its representation?
Is data abstraction possible in C?

 

[CBFalconer]

In C, an entity with contiguous storage that can be represented
by a single identifier, or an array of such entities.

Trollsdale has been annoying by creating several threads on this
subject, ignoring responses, and then crossposting it to make it
harder to kill the thread. Please ignore him. He knows, or
should know, better.

 

[Thomas Stegen]

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.

 

[Keith Thompson]

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.

 

[Keith Thompson]

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