What is an object?

[Douglas A. Gwyn]

Re: What is an object?

Tom Payne wrote:[color=blue]
> 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".[/color]

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]

Re: What is an object?

E. Robert Tisdale wrote:[color=blue]
> Are you acknowledging the existence of code objects?[/color]

No, I'm said what I meant.
[color=blue]
> Are you saying that ...[/color]

No, I'm saying that your decription of events
that transpired was wrong.
[color=blue]
> 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.[/color]

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

[Tom Payne]

Re: What is an object?

In comp.std.c Douglas A. Gwyn <DAGwyn@null.ne t> 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

[Mabden]

Re: What is an object?

"Tom Payne" <thp@cs.ucr.edu > wrote in message
news:cg9qr2$91h $4@glue.ucr.edu ...[color=blue]
> In comp.std.c Douglas A. Gwyn <DAGwyn@null.ne t> 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.[/color]

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.
[color=blue]
> : Don't you have anything better to do than to complain
> : about things that aren't causing any real problems?[/color]

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?
[color=blue]
> This confusing ambiguity is a very real problem, especially to those
> learning the language.[/color]

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

[Tom Payne]

Re: What is an object?

In comp.std.c Thomas Stegen <tstegen@cis.st rath.ac.uk> wrote:
[...][color=blue]
> 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.[/color]

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]

Re: What is an object?

Douglas A. Gwyn wrote:[color=blue]
>
> E. Robert Tisdale wrote:[/color]
[color=blue][color=green]
> > 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.[/color]
>
> No, it isn't. The C standard makes exactly the
> right distinction for its purposes.[/color]

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

[CBFalconer]

Re: What is an object?

pete wrote:[color=blue]
> Douglas A. Gwyn wrote:[color=green]
>> E. Robert Tisdale wrote:[/color]
>[color=green][color=darkred]
>>> 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.[/color]
>>
>> No, it isn't. The C standard makes exactly the
>> right distinction for its purposes.[/color]
>
> 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?[/color]

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

[Douglas A. Gwyn]

Re: What is an object?

Tom Payne wrote:[color=blue]
> 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?[/color]

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]

Re: What is an object?

In comp.std.c Douglas A. Gwyn <DAGwyn@null.ne t> wrote:[color=blue]
> Tom Payne wrote:[color=green]
>> 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?[/color]
>
> 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).[/color]

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

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]

Re: What is an object?

In comp.std.c James Kuyper <kuyper@wizard. net> wrote:
[...][color=blue]
> 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.[/color]

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]

Re: What is an object?

Tom Payne wrote:[color=blue]
> 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.[/color]

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]

Re: What is an object?

In comp.std.c Douglas A. Gwyn <DAGwyn@null.ne t> wrote:[color=blue]
> Tom Payne wrote:[color=green]
>> 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.[/color]
>
> 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.)[/color]

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

Tom Payne

[Tom Payne]

Re: What is an object?

In comp.std.c Douglas A. Gwyn <DAGwyn@null.ne t> wrote:
[...][color=blue][color=green]
>> 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?"[/color]
>
> That's not what happened.[/color]

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?
[color=blue][color=green]
>> 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.[/color][/color]
[color=blue]
> 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.[/color]

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]

Re: What is an object?

In comp.std.c E. Robert Tisdale <E.Robert.Tisda le@jpl.nasa.gov > wrote:[color=blue]
> Malcolm wrote:
>[color=green]
>> E. Robert Tisdale wrote:
>>[color=darkred]
>>>What is an object?
>>>[/color]
>>
>> 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.
>>[color=darkred]
>>>Where did this term come from?
>>>[/color]
>>
>> Not sure when "object" was first used in computing terms.
>> The important date is the use of "object-oriented".[/color]
>
> The term "object-oriented" was coined by Alan Kay (in 1967?)
>
> http://userpage.fu-berlin.de/~ram/pu...doc_kay_oop_en[/color]

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