What is an object?
Where did this term come from?
Does it have any relation
to the objects in "object oriented programming"?
Nov 14 '05
100  5143  ku****@wizard.net (James Kuyper) writes: "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.
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.)
--
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 <ks***@mib.org> wrote in message news:<ln************@nuthaus.mib.org>...
.... 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.
James Kuyper wrote:
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..
Thomas Stegen wrote: 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
http://www.faqs.org/faqs/by-newsgrou...mp.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.
E. Robert Tisdale wrote: 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.
In comp.std.c James Kuyper <ku****@saicmodis.com> 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
E. Robert Tisdale wrote: 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.
--
pete
Tom Payne wrote: In comp.std.c James Kuyper <ku****@saicmodis.com> 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. 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.
--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
In comp.std.c Joe Wright <jo********@comcast.net> wrote:
: Tom Payne wrote:
:
:> In comp.std.c James Kuyper <ku****@saicmodis.com> 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
Douglas A. Gwyn wrote: E. Robert Tisdale wrote:
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.
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.
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.
Don't you have anything better to do than to complain
about things that aren't causing any real problems?
E. Robert Tisdale wrote: 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.
In comp.std.c Douglas A. Gwyn <DA****@null.net> wrote:
: 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
"Tom Payne" <th*@cs.ucr.edu> wrote in message
news:cg**********@glue.ucr.edu... In comp.std.c Douglas A. Gwyn <DA****@null.net> wrote:
: 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.
--
Mabden
In comp.std.c Thomas Stegen <ts*****@cis.strath.ac.uk> 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.
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
Douglas A. Gwyn wrote:
E. Robert Tisdale wrote:
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.
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?
--
pete
pete wrote: Douglas A. Gwyn wrote: E. Robert Tisdale wrote:
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.
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.
--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison
Tom Payne wrote: 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).
In comp.std.c Douglas A. Gwyn <DA****@null.net> wrote: Tom Payne wrote: 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).
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
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
In comp.std.c James Kuyper <ku****@wizard.net> wrote:
[...] 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
Tom Payne wrote: 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.)
In comp.std.c Douglas A. Gwyn <DA****@null.net> wrote: Tom Payne wrote: 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.)
Wow!! That could be a very big improvement. Please keep us posted on
your progress.
Tom Payne
In comp.std.c Douglas A. Gwyn <DA****@null.net> wrote:
[...] 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
In comp.std.c E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote: 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
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
Tom Payne wrote: 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.
On Tue, 24 Aug 2004 06:13:09 +0000 (UTC) in comp.std.c, Tom Payne
<th*@cs.ucr.edu> wrote: In comp.std.c Douglas A. Gwyn <DA****@null.net> wrote:
[...] 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.
--
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
In comp.std.c Douglas A. Gwyn <DA****@null.net> wrote: Tom Payne wrote: 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.
Consider the variable declarations:
const int my_variable = 3; // in C
and
final double AVOGADRO = 6.022e23; // in Java
Tom Payne
Tom Payne <th*@cs.ucr.edu> writes: In comp.std.c Douglas A. Gwyn <DA****@null.net> wrote: Tom Payne wrote: 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.
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.
--
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.
Tom Payne wrote: E. Robert Tisdale wrote:
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
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.
Douglas A. Gwyn wrote: Tom Payne wrote:
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.
Variables may or may not be capable of being modified, depending on
the programming language. The term "variable" does not in itself connote
modifiability.
David Hopwood <da******************@blueyonder.co.uk>
Keith Thompson wrote: Tom Payne <th*@cs.ucr.edu> writes:In comp.std.c Douglas A. Gwyn <DA****@null.net> wrote:Tom Payne wrote:
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.
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*.
One would be incorrect. Consider the usage of "variable" in mathematics.
David Hopwood <da******************@blueyonder.co.uk>
In comp.std.c David Hopwood <da******************@blueyonder.co.uk> wrote: Douglas A. Gwyn wrote: Tom Payne wrote:
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.
Variables may or may not be capable of being modified, depending on
the programming language. The term "variable" does not in itself connote
modifiability.
I've not taught a course on principles of programming languages for
almost ten years, but the last time I looked at textbooks on the
subject, none of the used the term object in the sense that it is used
by the C and C++ standards. Rather, they defined a variable to
consist of some or all of the following:
- a name (in the sense of identifer)
- a memory location capable of holding a value (i.e., what C/C++
calls an object)
- a scope
- a lifetime
- a type.
Somewhere they implicitly or explicity spoke of anonymous (nameless)
variables, often with statements like "an array is a sequence of
variables indexed by a range of integers" -- visibly each of them
doesn't get its own name. So, what's a variable without a name? It
looks very much like what C/C++ calls an object.
I'm not saying that I prefer that terminology, but it's important and
often difficult to translate among the metalanguages for various
programming languages. Too often the same idea arises in multiple
computing contexts, each time with an different metaphoric
terminology.
Tom Payne
Tom Payne wrote: David Hopwood <wrote:
Douglas A. Gwyn wrote:
Tom Payne wrote:
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.
Variables may or may not be capable of being modified, depending on
the programming language. The term "variable" does not in itself connote
modifiability.
I've not taught a course on principles of programming languages
for almost ten years,
but the last time I looked at textbooks on the subject,
none of them used the term object in the sense that it is used
by the C and C++ standards. Rather, they defined a variable to
consist of some or all of the following:
- a name (in the sense of identifer)
- a memory location capable of holding a value
(i.e., what C/C++ calls an object)
- a scope
- a lifetime
- a type.
Somewhere they implicitly or explicity spoke of anonymous (nameless)
variables, often with statements like "an array is a sequence of
variables indexed by a range of integers" -- visibly each of them
doesn't get its own name. So, what's a variable without a name?
It looks very much like what C/C++ calls an object.
I'm not saying that I prefer that terminology,
but it's important and often difficult to translate
among the metalanguages for various programming languages.
Too often the same idea arises in multiple computing contexts,
each time with an different metaphoric terminology.
Part of the problem may be that many of the people involved
in writing the standards documents have never had
any formal training in programming languages or compiler design.
Concepts like type, object and variable have always had
the same meaning across all computer programming languages.
This overloading [narrowing] of the meaning
of certain common terms to facilitate the definition
of any particular language standard causes confusion
among programmers who must master several programming languages.
On Wed, 25 Aug 2004 02:27:34 GMT in comp.std.c, David Hopwood
<da******************@blueyonder.co.uk> wrote: Keith Thompson wrote: Tom Payne <th*@cs.ucr.edu> writes:In comp.std.c Douglas A. Gwyn <DA****@null.net> wrote:
Tom Payne wrote:
>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.
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*.
One would be incorrect. Consider the usage of "variable" in mathematics.
Mathematical use of the word variable is irrelevant to its use in
programming in general, and C in particular. I'm sure the compiler is
free to optimize away the storage unless & is used.
Please enlighten us as to the contexts in which variables are not
considered to vary in mathematics.
--
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
On Wed, 25 Aug 2004 02:25:45 GMT in comp.std.c, David Hopwood
<da******************@blueyonder.co.uk> wrote: Douglas A. Gwyn wrote: Tom Payne wrote:
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.
Variables may or may not be capable of being modified, depending on
the programming language. The term "variable" does not in itself connote
modifiability.
Would one not then tend to refer to the variable as a constant or
parameter, even if the language itself supports no such concepts?
--
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
In comp.std.c E. Robert Tisdale <E.**************@jpl.nasa.gov> wrote:
[...] I'm not saying that I prefer that terminology, but it's important
and often difficult to translate among the metalanguages for
various programming languages. Too often the same idea arises in
multiple computing contexts, each time with an different metaphoric
terminology.
Part of the problem may be that many of the people involved in
writing the standards documents have never had any formal training
in programming languages or compiler design.
Concepts like type, object and variable have always had the same
meaning across all computer programming languages. This overloading
[narrowing] of the meaning of certain common terms to facilitate the
definition of any particular language standard causes confusion
among programmers who must master several programming languages.
Many of the people involved in the C and C++ standardization efforts
were extremely knowledgeable of both the design and the implementation
of programming languages. The decision to use the term "object" for
what others (akwardly) called "anonymous variables" was probably made
in the mid eighties, well before "object-oriented programming" got to
be the pervasive notion that it is today. I can't criticize that
decision. I simply regret the confusion it causes.
Tom Payne
"E. Robert Tisdale" wrote:
.... snip ...
Part of the problem may be that many of the people involved
in writing the standards documents have never had
any formal training in programming languages or compiler design.
I am extremely weary of this continuous retrolling of this silly
subject. For the purposes of C an object is fully defined in the
standard. No more need be said.
I suggest everybody PLONK this thread. Trollsdale has returned to
his obnoxious ways.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
David Hopwood wrote: One would be incorrect. Consider the usage of "variable" in mathematics.
As opposed to "constant"?
E. Robert Tisdale wrote: Part of the problem may be that many of the people involved
in writing the standards documents have never had
any formal training in programming languages or compiler design.
How did you determine that? Anyway, most of the WG14
active participants certainly have had formal training
and experience in those areas.
Concepts like type, object and variable have always had
the same meaning across all computer programming languages.
Wrong.
Brian Inglis wrote: On Wed, 25 Aug 2004 02:27:34 GMT in comp.std.c, David Hopwood
<da******************@blueyonder.co.uk> wrote:
Keith Thompson wrote:
Tom Payne <th*@cs.ucr.edu> writes:
In comp.std.c Douglas A. Gwyn <DA****@null.net> wrote:
>Tom Payne wrote:
>
>
>>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.
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*.
One would be incorrect. Consider the usage of "variable" in mathematics.
Mathematical use of the word variable is irrelevant to its use in
programming in general, and C in particular. I'm sure the compiler is
free to optimize away the storage unless & is used.
The use in programming is derived directly from the mathematical use,
and is not inconsistent with it. An instance of a mutable variable in
a programming language can be viewed as referring to a fixed "slot" or
"cell", which can have a value that changes over time.
Please enlighten us as to the contexts in which variables are not
considered to vary in mathematics.
Variables are never allowed to directly vary over time -- i.e. to be
mutable -- in mathematics. Different instances of a variable can take
different values.
Doug Gwyn wrote: David Hopwood wrote: [...] Consider the usage of "variable" in mathematics.
As opposed to "constant"?
Yes. The difference between constants and variables is not that variables
are mutable, but that variables can have multiple instances.
David Hopwood <da******************@blueyonder.co.uk>
# The use in programming is derived directly from the mathematical use,
# and is not inconsistent with it. An instance of a mutable variable in
C is a bastard child of Fortran, Algol 60, and Algol 68. Algol 68 got
the terminology right. As usual, when C steals from Algol 68, it does
it in half-assed totally mucked up fashion. If you bothered to understand
the issue from Algol X, Algol W, and the rest, the whole notion of
lvalues and rvalues and references and dereferences and all the rest
would be much clearer.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
Haven't you ever heard the customer is always right?
Tom Payne <th*@cs.ucr.edu> wrote in message news:<cg**********@glue.ucr.edu>...
.... doesn't get its own name. So, what's a variable without a name? It
looks very much like what C/C++ calls an object.
More accurately, an object can be a variable, or it can be nameless.
Variables are always named. In C++, they're defined by that fact
(3p4): _variable_ basically means "declared object", and you can't
declare an object without giving it a name. I couldn't find comparable
wording in the C standard, however.
In article <10*************@corp.supernews.com>,
SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote: Algol 68 got the terminology right.
[...]If you bothered to understand
the issue from Algol X, Algol W, and the rest, the whole notion of
lvalues and rvalues and references and dereferences and all the rest
would be much clearer.
So clear in fact that none of us would feel the slightest urge to
write
real x = 1.2
instead of
ref real x = loc real := 1.2
-- Richard
James Kuyper wrote: Tom Payne <th*@cs.ucr.edu> wrote:
....
doesn't get its own name. So, what's a variable without a name? It
looks very much like what C/C++ calls an object.
More accurately, an object can be a variable, or it can be nameless.
No. Consider an object that is referred to by two distinct variable
instances (e.g. instances of global variables with external linkage in
different translation units). This shows that variable instances
*refer to* objects; an object cannot *be* a variable instance (or a
variable).
David Hopwood <da******************@blueyonder.co.uk> ku****@wizard.net (James Kuyper) writes: Tom Payne <th*@cs.ucr.edu> wrote in message
news:<cg**********@glue.ucr.edu>...
... doesn't get its own name. So, what's a variable without a name? It
looks very much like what C/C++ calls an object.
More accurately, an object can be a variable, or it can be nameless.
Variables are always named. In C++, they're defined by that fact
(3p4): _variable_ basically means "declared object", and you can't
declare an object without giving it a name. I couldn't find comparable
wording in the C standard, however.
Because there is no such wording in the C standard. The C standard
doesn't define the word "variable", and uses it only a few times.
(The usage is consistent with a variable being a declared object, but
there's not enough basis to decide, for example, whether arr[3] or
*ptr are considered "variables" or not.)
I suggest that the meaning of the word "variable" isn't a fruitful
topic for comp.std.c, unless you want to propose defining it in a
future standard.
--
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.
"CBFalconer" <cb********@yahoo.com> wrote in message
news:41**************@yahoo.com... "E. Robert Tisdale" wrote:
... snip ...
Part of the problem may be that many of the people involved
in writing the standards documents have never had
any formal training in programming languages or compiler design.
I am extremely weary of this continuous retrolling of this silly
subject. For the purposes of C an object is fully defined in the
standard. No more need be said.
I suggest everybody PLONK this thread. Trollsdale has returned to
his obnoxious ways.
Your continuous trolling every time ERT posts is beyond old. Why don't you
STFU if you don't have something to say.
In comp.std.c David Hopwood <da******************@blueyonder.co.uk> wrote:
[...] The use in programming is derived directly from the mathematical use,
and is not inconsistent with it. An instance of a mutable variable in
a programming language can be viewed as referring to a fixed "slot" or
"cell", which can have a value that changes over time.
My students claim to have been told by math teachers that:
- A variable is what you use when you don't know that you're talking
about.
- There are two kinds of numbers, constants and variables, and you
can tell which kind by whether its from the beginning alphabet
(constants) or the end of the alphabet (variables).
Tom Payne
Tom Payne wrote: David Hopwood wrote:
[...]
The use in programming is derived directly from the mathematical use,
and is not inconsistent with it. An instance of a mutable variable in
a programming language can be viewed as referring to a fixed "slot" or
"cell", which can have a value that changes over time.
My students claim to have been told by math teachers that:
- A variable is what you use when you don't know that you're talking
about.
- There are two kinds of numbers, constants and variables, and you
can tell which kind by whether its from the beginning alphabet
(constants) or the end of the alphabet (variables).
According to the American Heritage Dictionary of the English Language http://www.bartleby.com/61/
variable
NOUN: Mathematics
a. A quantity capable of assuming any of a set of values.
b. A symbol representing such a quantity. For example,
in the expression a^2 + b^2 = c^2, a, b, and c are variables.
constant
NOUN:
a. A quantity assumed to have a fixed value
in a specified mathematical context.
b. An experimental or theoretical condition, factor, or quantity
that does not vary or that is regarded as invariant
in specified circumstances.
Mabden wrote: Your continuous trolling every time ERT posts is beyond old. Why don't you
STFU if you don't have something to say.
I would plonk you right now, but I'm changing newsreaders soon. Remind
me (probably by saying something stupid) to plonk you later.
Brian Rodenborn This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Brandon J. Van Every |
last post by:
What's better about Ruby than Python? I'm sure there's something. What is
it?
This is not a troll. I'm language shopping and I want people's answers. I
don't know beans about Ruby or have...
|
by: Brett |
last post by:
What is the following code doing? I see evt and event but what is the difference?
<input type="radio" id="us_countryFlag1" name="us_country"
onclick="togglePurDec(event)">Yes
<script>...
|
by: Steven T. Hatton |
last post by:
I just read this in the description of how C++ is supposed to be
implemented:
"All external object and function references are resolved. Library
components are linked to satisfy external...
|
by: gulu man |
last post by:
Hi,
What is the substitute for COM objects in .NET?
How can I create something similar to com in .net?
Is it still possible?
Thank you
|
by: Jerzy Karczmarczuk |
last post by:
I thought that the following sequence
gl=0
def gen(x):
global gl
gl=x
yield x
s=gen(1)
|
by: Helge Jensen |
last post by:
I've got some data that has Set structure, that is membership, insert
and delete is fast (O(1), hashing). I can't find a System.Collections
interface that matches the operations naturally offered...
|
by: Rachel Suddeth |
last post by:
What is the difference between a managed/unmanaged resource, and how do you
tell which is which? I'm trying to understand how to write some Dispose()
methods, and we are supposed to put code that...
|
by: Jay |
last post by:
Everywhere I go (read/browse) I see these parameters....
ByVal sender As Object, ByVal e As System.EventArgs
Yet I never see them used within the function/method.
Could someone tell me what they...
|
by: darren |
last post by:
Hi
I have to write a multi-threaded program. I decided to take an OO
approach to it. I had the idea to wrap up all of the thread functions
in a mix-in class called Threadable. Then when an...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
