What is an object?

[E. Robert Tisdale]

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?

 

[Keith Thompson]

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.

 

[Brian Inglis]

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.

 

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

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:
.... def p(self):
.... print "Foo: "+`self.val`
.... def set(self, val):
.... self.val=val
.... def yo(self):
.... print "Yo"
........ def p(self):
.... print "Bar: "+`self.val`
.... def set(self, val):
.... self.val=val+2
....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]

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]

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]

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]

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.

 

[Keith Thompson]

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.

I don't think that's correct. ptr points to a "region of data storage
in the execution environment, the contents of which can represent
values" -- i.e., it points to an object. (An object needn't have a
type.)

 

[James Kuyper]

I don't think that's correct. ptr points to a "region of data storage
in the execution environment, the contents of which can represent
values" -- i.e., it points to an object. (An object needn't have a
type.)

The distinction I'm making is that ptr doesn't point at the whole
object, it just points at it's start. When you dereference a 'double
*', you retrieve the entire double object it points at. You can tell
the size of the object pointed at by sizeof(*p) for a pointer to
object type. ptr doesn't qualify.

 

[Douglas A. Gwyn]

The distinction I'm making is that ptr doesn't point at the whole
object, it just points at it's start.

Indeed there are in general multiple overlapping objects
at that location, and only when the ptr value is
converted to a pointer to some object type is it able to
be dereferenced to access an object, whose extent is
determined by the pointed-to type.
I think I'm on the hook to provide wording for a DR
response on this issue..

 

[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"?

From the comp.object faq
http://www.faqs.org/faqs/by-newsgroup/comp/comp.object.html

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

It seems to me that C objects are *precisely* the objects described
in the comp.object definition of OO.
The restriction of C objects to data objects
appears to be unnecessary and unfortunate.
It seems to deny the existence of code objects^#
even though you can obtain a pointer to them.

Some very narrow interpretations of "object" seem to define it
as an abbreviation for a "typeless block of data storage"
even though the notion of values is meaningless
unless the object has a type.

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

My question is, "Was the existing notion of object considered
when the definition was overloaded [narrowed] to help describe
the C computer programming language in the standards documents?"
The problem is that some people use this very narrow definition
[of objects] to confine their own intellect as well as
the thinking of other [object oriented] C programmers.



# I say "code objects" because Stroustrup has already given
"function objects" another meaning.

 

[Douglas A. Gwyn]

It seems to me that C objects are *precisely* the objects described
in the comp.object definition of OO.

No, although C++ objects come close. (C is not C++.)

The restriction of C objects to data objects
appears to be unnecessary and unfortunate.
It seems to deny the existence of code objects^#
even though you can obtain a pointer to them.

No, it allows "code objects" to exist in a separate
address space from data objects. This is intentional.

My question is, "Was the existing notion of object considered
when the definition was overloaded [narrowed] to help describe
the C computer programming language in the standards documents?"

That's not what happened.

The problem is that some people use this very narrow definition
[of objects] to confine their own intellect as well as
the thinking of other [object oriented] C programmers.

I doubt that very much. C's use of "object" is
generally confined to technical discussions about
C programming, where it is exactly the right concept.

 

[Tom Payne]

[...]
: 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).

Unfortunately, some top experts consciously or unconsciously seem to
follow the (incorrect) practice of using the term "pointer" only for
pointer objects. They explicitly say "pointer value" when speaking of
a pointer rvalue.

- "A pointer is a variable that contains the address of another
variable." [K&R, p.89]

- "When using a pointer, two objects are involved: the pointer
itself and the object pointed to."
[The C++ Programming Language, p.96]

Many textbooks and instructors follow them and create unnecessary
confusion in the minds of students.

Tom Payne

 

[pete]

What do you mean by type?

Does a C type depend upon its representation?

There are three major catagories of types:
function types, object types, and incomplete types.

Function types are defined by the return type and the parameter types.
memcpy and memmove are two different fuctions of the same type.
Representation has nothing to do with function types,
because functions are not objects.

 

[Joe Wright]

[...]
: 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).

Unfortunately, some top experts consciously or unconsciously seem to
follow the (incorrect) practice of using the term "pointer" only for
pointer objects. They explicitly say "pointer value" when speaking of
a pointer rvalue.

- "A pointer is a variable that contains the address of another
variable." [K&R, p.89]

- "When using a pointer, two objects are involved: the pointer
itself and the object pointed to."
[The C++ Programming Language, p.96]

Many textbooks and instructors follow them and create unnecessary
confusion in the minds of students.

Tom Payne

With all due respect Tom, unless you have your tongue firmly in
cheek, it is the ambiguity which causes the confusion. There are
important differences between objects and values. K&R has it right
(this time). If only BWK had described the pointer value as
'address' in his famous book, a lot of confusion might have been
avoided. IMO.

 

[Tom Payne]

: Tom Payne 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).
:>
:> Unfortunately, some top experts consciously or unconsciously seem to
:> follow the (incorrect) practice of using the term "pointer" only for
:> pointer objects. They explicitly say "pointer value" when speaking of
:> a pointer rvalue.
:>
:> - "A pointer is a variable that contains the address of another
:> variable." [K&R, p.89]
:>
:> - "When using a pointer, two objects are involved: the pointer
:> itself and the object pointed to."
:> [The C++ Programming Language, p.96]
:>
:> Many textbooks and instructors follow them and create unnecessary
:> confusion in the minds of students.
:>
:> Tom Payne
:
: With all due respect Tom, unless you have your tongue firmly in
: cheek, it is the ambiguity which causes the confusion.

This ambiguity seems to exist with all C types. E.g., following
the declaration

int i;

the object i is said to be an int, and similarly 3 is said to be an
int. Unfortunately, both are (ambiguously) referred to as "ints".

: There are important differences between objects and values.

Exactly. In fact, in some languages (e.g., Algol68) int values and
int objects have distinct types.

: K&R has it right (this time).

Would it be correct to say that "An int is a variable that contains an
integer." ? If so, it is ambiguous at best to say that INT_MAX is an
int.

: If only BWK had described the pointer value as
: 'address' in his famous book, a lot of confusion might have been
: avoided. IMO.

I'd be happy with that, but the standard does not speak of
"addresses". It does speak of "address constants", which are constant
expressions of pointer types.


I don't like the ambuity of calling both T-values and T-objects Ts.
But, IMHO, if we are going to tolerate that ambiguity, we ought to use
it consistently, rather than shifting to a different terminology in
the case where T is a pointer type.

Tom Payne

 

[E. Robert Tisdale]

No, although C++ objects come close. (C is not C++.)


No, it allows "code objects" to exist in a separate
address space from data objects. This is intentional.

Are you acknowledging the existence of code objects?

My question is, "Was the existing notion of object considered
when the definition was overloaded [narrowed] to help describe
the C computer programming language in the standards documents?"

That's not what happened.

What *did* happen?
Are you saying that the existing notion of object
was *not* considered ehen the definition was overloaded
to help describe the C computer programming language?

The problem is that some people use this very narrow definition
[of objects] to confine their own intellect as well as
the thinking of other [object oriented] C programmers.

I doubt that very much. C's use of "object" is
generally confined to technical discussions about
C programming, where it is exactly the right concept.

No.
The abstract notion of object is much more important
to programming in C or any other language
than the special meaning given to the term
in the context of the C standards documents.