What is an object?

[Douglas A. Gwyn]

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

That's *colloquial* usage; "int" is actually the name
of a type. In formal specifications, one usually sees
"object of type int" or "value" (the type that the
value has is inferred from the context). In practical
work, the relationships are almost always clear enough.
Don't you have anything better to do than to complain
about things that aren't causing any real problems?

 

[Douglas A. Gwyn]

Are you acknowledging the existence of code objects?

No, I'm said what I meant.

Are you saying that ...

No, I'm saying that your decription of events
that transpired was wrong.

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.

No, it isn't. The C standard makes exactly the
right distinction for its purposes.

 

[Tom Payne]

: Tom Payne wrote:
:> 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".
:
: That's *colloquial* usage; "int" is actually the name
: of a type. In formal specifications, one usually sees
: "object of type int" or "value" (the type that the
: value has is inferred from the context). In practical
: work, the relationships are almost always clear enough.

The OP for this subthread, Mabden, was confused by the ambiguity in
colloquial use of the term "pointer":

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?

I've merely noted and lamented the fact that this ambiguity occurs
over all types in discussions of C programming.

: Don't you have anything better to do than to complain
: about things that aren't causing any real problems?

This confusing ambiguity is a very real problem, especially to those
learning the language.

Tom Payne

 

[Mabden]

: Tom Payne wrote:
:> 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".
:
: That's *colloquial* usage; "int" is actually the name
: of a type. In formal specifications, one usually sees
: "object of type int" or "value" (the type that the
: value has is inferred from the context). In practical
: work, the relationships are almost always clear enough.

The OP for this subthread, Mabden, was confused by the ambiguity in
colloquial use of the term "pointer":

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?

I've merely noted and lamented the fact that this ambiguity occurs
over all types in discussions of C programming.

And I'm still following it with interest. I would say "confused" is an
overstatement, more like curious as to the standard definition, and the
Standard's definition. I had recently had another fine point about the
language clarified (the null pointer vs location zero thread; it may yet be
going on...) and wanted to make sure I had this idea correct in reference to
what the purists believe (or know).

Tom is right, my question was certainly not about the word "int" being used
for the number 3 or some constant.

: Don't you have anything better to do than to complain
: about things that aren't causing any real problems?

In that vein, how about using normal indenting characters? Some people use
tools to make the wrapping work better and a colon or pound sign messes
them up. I know you want to feel special, but can't you just use greater
than in your posts and buy a dog, instead?

This confusing ambiguity is a very real problem, especially to those
learning the language.

It helps people have intelligent conversations (arguments?) when everyone is
on the same page. It is unfortunate when the thread backslides because
someone didn't read the entirety and jumps all over a post that was gone
over 7 posts back. The null pointer thread kept doing that every 4 or 5
posts.

 

[Tom Payne]

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.

C objects are commonly viewed as objects in the sense of Booch et al
via the following terminology mapping:
- "Value" is a form of state.
- "Address" is a form of identity.
- "Operations" are a form of behavior.

Going the other way, for any object in the sense of Booch et al, we
can use a struct as a description record (a.k.a. descriptor,
a.k.a. control block). We can use data members to represent the
states of the object's attributes and functions or pointers to
functions to represent object's behaviors. (That's basically how
things were done in Simula 67.)

Tom Payne

 

[pete]

E. Robert Tisdale wrote:

No, it isn't. The C standard makes exactly the
right distinction for its purposes.

But suppose you want to show off how much you know about C
but you don't know the standard and don't want to learn it
because you already know so much,
surely you must agree that having the standard is bad in that case?

 

[CBFalconer]

But suppose you want to show off how much you know about C
but you don't know the standard and don't want to learn it
because you already know so much, surely you must agree that
having the standard is bad in that case?

ITYM "don't know". Absolutely. It also makes an excellent excuse
for generating untold misinformation and arguments, and general
trolling. All this provides much practice in ignoring any
accurate information, and impressing dewey eyed newbies. It is
also a grand excuse for crossposting and tying up multiple
newsgroups.

 

[Douglas A. Gwyn]

The OP for this subthread, Mabden, was confused by the ambiguity in
colloquial use of the term "pointer":
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?

But the misundestanding had nothing to do with the latest
issue. He failed to distinguish between the implementation
of a function (its instruction stream, not necessarily in
data space) and a pointer to a function, which can be stored
in an object (always in data space).

 

[Tom Payne]

But the misundestanding had nothing to do with the latest
issue. He failed to distinguish between the implementation
of a function (its instruction stream, not necessarily in
data space) and a pointer to a function, which can be stored
in an object (always in data space).

Please re-read the two sentences that I quoted above. IIUC, he was of
the opinion that:
- in most contexts, a function name designates a function pointer
- pointers are objects, just as K&R says they are.
The obvious conclusion being that function names designate
(pointer-to-function) objects.

And that was the misunderstanding that James Kuyper addressed in his
followup:

There's an ambiguity here that complicates the discussion. "pointer" is
often used as a short version of either "pointer value" or "pointer
object". ...

Tom Payne

 

[E. Robert Tisdale]

Always remember others may hate you but those who hate you don't win
unless you hate them. And then you destroy yourself.
Richard M. Nixon (1913 - 1994), in his White House farewell

 

[Tom Payne]

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 recall reading somewhere that "the type of an object is determined
by the types of the lvalues used to access it" or words to that
effect.

Tom Payne

 

[Douglas A. Gwyn]

I recall reading somewhere that "the type of an object is determined
by the types of the lvalues used to access it" or words to that
effect.

That's the specific issue I'm supposed to devise
proposed DR response wording for. The idea is that
the type is *impressed* upon the storage by the
type used for the access, and if there is a
mismatch with th alignment requirements, or if it
is a read access that doesn't match the type of the
sequentially last write access to the same object,
the behavior is undefined. (There are some
explicit exceptions in the spec, to facilitate
certain important programming techniques.)

 

[Tom Payne]

That's the specific issue I'm supposed to devise
proposed DR response wording for. The idea is that
the type is *impressed* upon the storage by the
type used for the access, and if there is a
mismatch with th alignment requirements, or if it
is a read access that doesn't match the type of the
sequentially last write access to the same object,
the behavior is undefined. (There are some
explicit exceptions in the spec, to facilitate
certain important programming techniques.)

Wow!! That could be a very big improvement. Please keep us posted on
your progress.

Tom Payne

 

[Tom Payne]

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.

I'm curious as to what did happen. The Simula67 definition had been
around for six years when C was announced. Strachey's notion of
lvalue which had almost identical meaning had been around for the same
length of time. What was the term "object" chosen?

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.

There was also the notion of (nameless) variable, which was often used
for the same notion in discussions of other programming langauges.

Tom Payne

 

[Tom Payne]

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

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

IIUC, Simula67 was published in 1967 and included inheritance. Per
Alan Kay's posting cited above:

I didn't like the way Simula I or Simula 67 did inheritance (though I
thought Nygaard and Dahl were just tremendous thinkers and
designers). So I decided to leave out inheritance as a built-in
feature until I understood it better.

It appears to me that the credit goes to the Scandanavians.

Tom Payne

 

[Douglas A. Gwyn]

There was also the notion of (nameless) variable, which was often used
for the same notion in discussions of other programming langauges.

Not the same; a variable is capable of being modified,
while a constant object is not.

 

[Brian Inglis]

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.

I'm curious as to what did happen. The Simula67 definition had been
around for six years when C was announced. Strachey's notion of
lvalue which had almost identical meaning had been around for the same
length of time. What was the term "object" chosen?

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.

There was also the notion of (nameless) variable, which was often used
for the same notion in discussions of other programming langauges.

But C supports much more general expressions than just a variable for
referring to an object. Discussions of nameless variables and
functions always seems to bring in the anonymous adjective, which gets
unwieldy, so calling a (not necessarily but possibly anonymous)
storage instance an object does simplify discussions. It is also
accurate within the limited context of C, and a lot of interfaces
developed in C have provided more object-oriented interfaces: the Unix
device driver interface is a pure vtable, and AFAICT the vfs, NFS, and
RPC interfaces are object-oriented in the usual sense of combining
functions and data.

 

[Tom Payne]

Not the same; a variable is capable of being modified,
while a constant object is not.

Consider the variable declarations:

const int my_variable = 3; // in C

and

final double AVOGADRO = 6.022e23; // in Java

Tom Payne

 

[Keith Thompson]

Consider the variable declarations:

const int my_variable = 3; // in C

and

final double AVOGADRO = 6.022e23; // in Java

One could argue that my_variable isn't a variable because it isn't
*able* to *vary*. The current C standard doesn't define the term
"variable", and uses it only a few times.

Of course, the standard could have defined "variable" in a way that
covers my_variable; that would have been consistent, but it would
undoubtedly have caused confusion.

 

[E. Robert Tisdale]

IIUC, Simula67 was published in 1967 and included inheritance.
Per Alan Kay's posting cited above:

I didn't like the way Simula I or Simula 67 did inheritance (though I
thought Nygaard and Dahl were just tremendous thinkers and
designers). So I decided to leave out inheritance as a built-in
feature until I understood it better.

It appears to me that the credit goes to the Scandanavians.

Alan Kay coined the phrase "object-oriented".
Evidently, Alan Kay believes that the objects that he had in mind
were the objects described by Nygaard and Dahl.