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]

E. Robert Tisdale schrieb:

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]

E. Robert Tisdale wrote:

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]

On Mon, 16 Aug 2004 23:18:28 -0400, E. Robert Tisdale wrote:

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]

E. Robert Tisdale wrote:

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

--
Thomas.

[Mabden]

"Douglas A. Gwyn" <DA****@null.net> wrote in message
news:Tb********************@comcast.com...

E. Robert Tisdale wrote:

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.

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?

--
Mabden

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

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

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.thefreedictionar...%20programming
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]

"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

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

[...]

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.

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Eric Sosman]

Keith Thompson wrote:

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.

--
Er*********@sun.com

[Niklas Matthies]

On 2004-08-17 19:55, Eric Sosman wrote:

Keith Thompson wrote:

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]

Mabden wrote:

"Douglas A. Gwyn" <DA****@null.net> wrote ...

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

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]

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.

[E. Robert Tisdale]

James Kuyper wrote:

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.

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

[CBFalconer]

Malcolm wrote:

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

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.

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.

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

[Thomas Stegen]

E. Robert Tisdale wrote:

Thomas Stegen wrote:

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.

--
Thomas.

[Keith Thompson]

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

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> 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".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Niklas Matthies]

On 2004-08-17 21:45, E. Robert Tisdale wrote:
:

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

In Python perhaps, but not in Java.

-- Niklas Matthies

[CBFalconer]

"E. Robert Tisdale" wrote:

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

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

[CBFalconer]

"E. Robert Tisdale" 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.

Google for "reading for comprehension"

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

[E. Robert Tisdale]

Malcolm wrote:

E. Robert Tisdale wrote:

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 term "object-oriented" was coined by Alan Kay (in 1967?)

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

[E. Robert Tisdale]

Niklas Matthies wrote:

On 2004-08-17 19:55, Eric Sosman wrote:

Keith Thompson wrote:

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?

[E. Robert Tisdale]

Michael B Allen wrote:

E. Robert Tisdale wrote:

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.

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]

Keith Thompson wrote:

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

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?

[E. Robert Tisdale]

Thomas Stegen wrote:

E. Robert Tisdale wrote:

Thomas Stegen wrote:

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?

[E. Robert Tisdale]

Keith Thompson wrote:

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?

[Martin Ambuhl]

CBFalconer wrote:

"E. Robert Tisdale" wrote:

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]

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

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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Keith Thompson <ks***@mib.org> writes:

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

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Eric Schmidt]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<cf**********@nntp1.jpl.nasa.gov>...

Keith Thompson wrote:

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

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.

--
Eric Schmidt

[Jack Klein]

On Tue, 17 Aug 2004 10:34:30 GMT, "Mabden" <mabden@sbc_global.net>
wrote in comp.lang.c:

"Douglas A. Gwyn" <DA****@null.net> wrote in message
news:Tb********************@comcast.com...

E. Robert Tisdale wrote:

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.

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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[E. Robert Tisdale]

Eric Schmidt wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<cf**********@nntp1.jpl.nasa.gov>...

Keith Thompson wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
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?

[Douglas A. Gwyn]

E. Robert Tisdale wrote:

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]

E. Robert Tisdale wrote:

So void is not a type?

That's not what he said nor implied.

[Douglas A. Gwyn]

E. Robert Tisdale wrote:

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]

E. Robert Tisdale wrote:

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.

[E. Robert Tisdale]

Jack Klein wrote:

Mabden wrote:

Douglas A. Gwyn wrote:

E. Robert Tisdale wrote:

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.

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?

[RCollins]

Douglas A. Gwyn wrote:

E. Robert Tisdale wrote:

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?

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[RCollins]

E. Robert Tisdale wrote:

Eric Schmidt wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:<cf**********@nntp1.jpl.nasa.gov>...

Keith Thompson wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
> 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).

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[E. Robert Tisdale]

RCollins wrote:

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".
I don't think so either.
But consider

int* p = (int*)malloc(42);

How many objects of type int does p point to?
10 1/2?

Consider

typedef struct X {
int* p;
} X;

X x; // uninitialized

Is x an object of type [struct] X
even if x contains an invalid value of type [struct] X?
(It may, infact, be 42 objects).

[Keith Thompson]

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

Eric Schmidt wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in
message news:<cf**********@nntp1.jpl.nasa.gov>...

Keith Thompson wrote: [...]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?

Just in case anyone had any doubt that ERT is a deliberate troll...

Any reasonably intelligent person who's been following this thread
would be aware that (assuming malloc() succeeds and returns a non-null
result):

ptr is a pointer to an object.
void is an incomplete type.
void is not an object type.
An object cannot have an incomplete type.
An object therefore cannot have type void.
The region of data storage to which ptr points is an object.
This object has no inherent type.
In particular, it is not of type void (since no object can be of
type void, since void is not an object type).

I leave it to each reader to draw his or her own conclusion about
ERT's motivations.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Brian Inglis]

On Tue, 17 Aug 2004 15:28:19 -0700 in comp.std.c, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote:

Keith Thompson wrote:

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?

To allow for implementation on Harvard architecture machines, in which
instructions and data reside in separate address spaces, normally with
the instructions unmodifiable and sometimes unreadable.
Some of the PDP-11s on which C grew up supported separate I and D
address spaces, allowing double the total address space without any
additional address bits. References to code at address X referred to
that location in I space, whereas references to data at address X
referred to the same offset but in D space. Which address space was
referenced was implicit in the instruction set: control flow
instructions referred to I space, other operations on memory referred
to D space.

You must be familiar only with von Neumann architecture machines, in
which only a single address space is supported, holding both
instructions and data, allowing self-modifying code, data overwriting
instructions, and a number of nasty side effects now being exploited
to break into and take over systems.

There are pros and cons to both approaches and examples of both in
current architectures, although I believe only some small embedded
architectures are Harvard to save address bits, most architectures are
now von Neumman. On the von Neumann architectures, some designers
elect to separate the L1 caches into I and D sets, others have a
single unified cache.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Br**********@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply

[Tim Rentsch]

An "object" in C is basically a hunk of memory that can hold
"data".

If there is a file scope static variable defined thusly:

static int xyz = 12;

the memory occupied by that variable may rightly be called an
object. (Please, no pedantic quibbles about the difference
between the variable and the name "xyz"; everyone here should
know what is meant when I say "that variable".)

Similarly, if there is a file scope static 'struct' variable

static struct {
int one;
int two;
} xyz_struct;

the memory occupied by the variable 'xyz_struct' also may
rightly be called an object. It is also true, if I understand
correctly, that the memory occupied by 'xyz_struct.one' is
properly called "an object" according to the C standard.

Or, to say this another way, an object in C is something that
can be "fetched out of" or "stored into" by means of an
assignment statement (assuming of course that a 'const' type
qualifier doesn't get in the way).

Which areas of memory are "objects" and which are not? Only
those that can (conformantly) be "fetched out of" or "stored
into" (and usually both). Hence functions are not objects; if
there is a function named 'foo' we certainly can't say

foo = (any expression you choose);

We can say

some_variable = foo;

but that's only because the function 'foo' is invisibly
converted to a pointer-to-function by taking its address; the
actually memory occupied by the function is not affected.

Is memory returned by 'malloc()' an object? Certainly some of
it can be; for example

* (int *) malloc( sizeof(int) ) = 12;

will store into some of the memory that the 'malloc()' call
returned. But perhaps not all of it - the amount of memory
returned might very well be 847 bytes, and the assignment will
store only into the first few (probably 4) bytes of that memory.
So in this hypothetical case we have a 4 byte object in an 847
byte area of memory.

Does an object have a "type"? The memory by itself does not --
memory allocated by malloc() has no intrinsic "type". But
whenever the memory is actually accessed there is effectively a
type, depending on how the memory is accessed. For example:

void * raw = malloc( sizeof(int) );
int * ip = raw;
unsigned int * uip = raw;
short * sp = raw;

*ip = 12;
*uip = 12;
*sp = 12;

Here the memory is variously an "int object", "unsigned int
object", and "short object". (Incidentally the code is running
on a PDP-11 where 'int' and 'short' are both only 2 bytes.)

Now, what is a type? This question is a tricky one because
historically there were two distinct notions captured in a
single term. In fact in early programming languages like
FORTRAN and Algol and Pascal (and also C), the two notions have
a natural one-to-one correspondence so it's very natural to
think of them as synonymous. Later people started to understand
that the compile-time notion of "type" and the run-time notion
of "object generator" are different (see for example the paper
by Borning and Ingalls in "Proceedings of the 9th ACM
SIGPLAN-SIGACT symposium on Principles of programming languages"
[1982]). The basics are these:

* "Type" is a compile-time notion that is a (partial)
specification of the structure of values that will
exist at runtime. Syntactic elements - basically,
expressions - are the things that have a "type"

* Values that exist at run-time have a structure, or
a representation, or a layout; there isn't a commonly
accepted term for this notion (sometimes the term
"run-time type" is used). In an object-oriented
language like C++ or Java or Smalltalk, it (usually)
would be a 'class' -- that is, a class is what generates
an "object" (different sense of the word "object" here),
and the class of an object also defines its structure.

The important thing here is that classes and types are different
- an object in an OOP language will have only one class over
its lifetime, but may be accessed by way of different types
at different times.

Incidentally, these two uses of the term "object" are probably
most confusing in C++, which uses "object" by itself in much
the same way that C does. So, in order to differentiate the
two kinds of "objects", C++ calls values that are instances
of classes "class objects". (That's an unfortunate choice
of terminology because Smalltalk uses the term "class object"
to mean something very different, but that's another topic
altogether.)

Now, last question - is the term "object" of C related to the
term "object" of "Object-Oriented Programming"? For starters,
the terms clearly do not mean the same thing - witness C++ using
different terms for normal C-like objects and instances of
classes, "class objects". So the two notions aren't synonymous.

However, I believe there has been some influence of the OOP term
on the C term. (Not causation, just influence.) This influence
may be seen, for example, in documentation describing the (now
very old) Intel i432 architecture. For that connection, and a
statement of what the essential elements of "object"s in OOP
are, see "Object Oriented Programming", SIGPLAN Notices 1982.

So I hope that answers Mr. Tisdale's questions.

[James Kuyper]

E. Robert Tisdale wrote:
....

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

Because it isn't "a region of data storage in the execution environment,
the contents of which can represent values".

It isn't a region of data storage. It might be stored in memory, but
that's storage for machine code, not data storage, and it might not be
stored in a single region, but rather in multiple disconnected regions.
If a function returns a value, and refers to nothing stored elsewhere
(as, for example, function parameters, external identifiers, or static
objects), then the machine code that makes up that function arguably
could be considered as a representation of that value. In fact, under
precisely those conditions an aggressively optimizing compiler could
replace:

int func() { /* lots of complicated code. */ }

with the machine code equivalent of:

int func () {
static const int i= // specific integer literal that matches
// the result of compiling and executing the actual function.
;
return i;
}

However, functions which can be considered to contain the entire
representation of the value that they return are rare; most of them
produce a different value for different arguments, and many of them
return no value at all.

[G. S. Hayes]

Tim Rentsch <tx*@alumnus.caltech.edu> wrote in message news:<kf*************@alumnus.caltech.edu>...

The important thing here is that classes and types are different
- an object in an OOP language will have only one class over
its lifetime, but may be accessed by way of different types
at different times.

As long as we're being off-topic...

This is not true in general. In many languages (Smalltalk and Python
come to mine), an object's class can change during its lifetime.

Example in Python:

class foo: .... def p(self):
.... print "Foo: "+`self.val`
.... def set(self, val):
.... self.val=val
.... def yo(self):
.... print "Yo"
.... class bar: .... def p(self):
.... print "Bar: "+`self.val`
.... def set(self, val):
.... self.val=val+2
.... a=foo()
a.set(42)
a.p() Foo: 42 a.yo() Yo a.__class__=bar # Looky here ma!
a.p() Bar: 42 # Still 42, but a bar... a.set(31337)
a.p() Bar: 31339 a.yo()

AttributeError: bar instance has no attribute 'yo'

And it's easy to show that, e.g., the memory location of "a" remains
unchanged throughout (and external references to "a", like list
entries or whatever, remain valid)

Not, in general, a good idea to do things like this, but possible (and
sometimes useful for metaprogramming). Even inheritance trees can be
restructured at runtime if you're sufficiently brave or foolish.

[Douglas A. Gwyn]

E. Robert Tisdale wrote:

int* p = (int*)malloc(42);
How many objects of type int does p point to?
One.
typedef struct X {
int* p;
} X;
X x; // uninitialized
Is x an object of type [struct] X
even if x contains an invalid value of type [struct] X?

Yes.

[James Kuyper]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<cf**********@nntp1.jpl.nasa.gov>...
....

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?

C types possess a set of possible values. You might describe the set
of operations that can be applied to a value of a given type as the
'methods' that can be applied to it, though the C standard doesn't use
such terminology.

The key difference is that C types are concrete; ADTs are, as their
name suggests, abstract. As a result, C types have several additional
characteristics that are not part of an ADT: they have a size, an
alignment requirement, and a specified mapping between the bit pattern
stored in an object, and the value that it would represent if
interpreted as an object of the specified type. In particular, a C
type can possess something that would be meaningless for an ADT: trap
representations - bit patterns that don't represent any value.

[James Kuyper]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<cf**********@nntp1.jpl.nasa.gov>...
E. Robert Tisdale wrote:

Eric Schmidt wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<cf**********@nntp1.jpl.nasa.gov>...

Keith Thompson wrote: .... 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?

Correct. It points at a memory location, which happens to be the start
of the object that was allocated by malloc. However, it doesn't point
at the object itself, because it isn't a pointer to an object type.

[James Kuyper]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<cf**********@nntp1.jpl.nasa.gov>...
E. Robert Tisdale wrote:

Eric Schmidt wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:<cf**********@nntp1.jpl.nasa.gov>...

Keith Thompson wrote: .... 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?

Correct. It points at a memory location, which happens to be the start
of the object that was allocated by malloc. However, it doesn't point
at the object itself, because it isn't a pointer to an object type.