🚀 go-pugleaf

In article <1992Dec27.050118.1628@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
|The desired feature is:
|Two pointers to the same type, which point to distinct objects
|of that type, compare not equal.

Can you define your terms for us?

"Two pointers" means what?

"to the same type" means what?

"distinct objects" means what?

"of that type" means what?

"compare not equal" means what?

I'm sure each of these things seems clear to you, yet they are not.

In article <1992Dec30.184614.5551@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
> In article <1992Dec27.050118.1628@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
> |The desired feature is:
> |Two pointers to the same type, which point to distinct objects
> |of that type, compare not equal.
> 
> Can you define your terms for us?

> I'm sure each of these things seems clear to you, yet they are not.

I'm talking about expressions with equality operators,
i.e. 5.10 of the ARM.  By "two pointers to the same type" I mean
to address just those cases in which both operands are pointer-type
expressions, and in which the types of the expressions are
	[const/volatile] pointer to [const/volatile] type A
and
	[const/volatile] pointer to [const/volatile] type B
where A and B are the "same type".  (I spell this out to indicate that
this is concerned with the static expression type, not the type of some
object, possibly enclosing the one pointed to.)

"Same type" is a term used repeatedly in the ARM.  It has its limitations,
but is adequate for my purpose.

"Point to distinct objects" would imply two things:
(1) Each operand points to one object (not a function, and is not null or
    invalid).
(2) The objects are not identicial.  I hope to say more about this in 
    another article.

The case I'm concerned with is limited to "objects of that type", i.e.
each operand points to a properly constructed object of type A (which may
be a subobject of an enclosing object constructed with a different type).

"Compare not equal" is self-evident; the C standard uses the same kind
of wording.  It means that the result of the operator != is 1 (TRUE) and
the result of the operator == is 0 (FALSE).
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com

In article <1992Dec30.184614.5551@microsoft.com> (Jim Adcock) writes:
> Can you define your terms for us?

> "distinct objects" means what?
It means the objects are not identical.  

I was going to say that the standard for C++ needs to spell out what it
means for object to be identical in a better way than just by
     1. An object is a region of storage.
     2. A definition or a new expression reserves the storage
        needed by the object.
These two rules leave things much more loose than necessary when objects
require no storage.  But note that section 1.3 of the working paper 
(The C++ Memory Model) says:

	The constructs in a C++ program create, refer to, access, and
	manipulate objects in memory.  Each object (except bit-fields)
	occupies one or more contiguous bytes.

I missed this a while back when enumerating the features of the ARM and
working paper which supported
> The desired feature is:
>     Two pointers to the same type, which point to distinct objects
>     of that type, compare not equal.
This excerpt from 1.3 gives the general rule I was seeking, because
objects can be distinguished by the storage reserved for them.

The excerpt may raise a few questions.

	How much freedom does it leave a compiler to optimize away
	an object's bytes (by application of the "as if" rule, etc.)?
	I think a good deal of freedom, because the working paper
	doesn't define the results if a program attempts to refer to
	or manipulate the bytes of an object.

	Does it govern base class subobjects?  As I understand it,
	base class subobjects are objects, and hence are covered.

	Does it belong in the C++ standard?  I'd say yes, given that
	compilers will for many practical purposes be able to 
	optimize away unneeded bytes.

--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com
	

In article <1992Dec31.170223.21637@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
>	Does it govern base class subobjects?  As I understand it,
>	base class subobjects are objects, and hence are covered.

	One consequence: abstract objects can exist.

	Corollary: such objects have states not accessible via
	the contiguous storage allocated for them.
	(via virtual function calls)


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------

pkt@lpi.liant.com (Scott Turner) writes:

>(Jim Adcock) writes:
>> "distinct objects" means what?
>It means the objects are not identical.  
>
>I was going to say that the standard for C++ needs to spell out what it
>means for object to be identical in a better way than just by
>     1. An object is a region of storage.
>     2. A definition or a new expression reserves the storage
>        needed by the object.
>These two rules leave things much more loose than necessary when objects
>require no storage.  But note that section 1.3 of the working paper 
>(The C++ Memory Model) says:
>
>	The constructs in a C++ program create, refer to, access, and
>	manipulate objects in memory.  Each object (except bit-fields)
>	occupies one or more contiguous bytes.

Let me just interject: what is the motivation for the above (as opposed
to "... occupies zero or more contiguous bytes")?
It seems to me that it is there primarily as an attempt to ensure some
sort of guarantee about pointer comparisons. (Are there any other reasons?)
However, the murkiness of the concepts involved in "object identity" appears
to make it very difficult or impossible to provide such guarantees.

If indeed it is the case that the above wording has failed to achieve its
purpose, then there are strong efficiency arguments which suggest that it
should be modified.

>I missed this a while back when enumerating the features of the ARM and
>working paper which supported
>> The desired feature is:
>>     Two pointers to the same type, which point to distinct objects
>>     of that type, compare not equal.
>This excerpt from 1.3 gives the general rule I was seeking, because
>objects can be distinguished by the storage reserved for them.
>
>The excerpt may raise a few questions.
>
>	How much freedom does it leave a compiler to optimize away
>	an object's bytes (by application of the "as if" rule, etc.)?
>	I think a good deal of freedom, because the working paper
>	doesn't define the results if a program attempts to refer to
>	or manipulate the bytes of an object.

Perhaps, but
	"The _sizeof_ operator yields the size, in bytes, of its operand".
I think that it would be a very brave compiler-writer whose compiler
made it unreliable to write() an object and read() it in again, because
	read(fd, &object, sizeof object);
randomly trashes the bytes past the end of the object.

>	Does it govern base class subobjects?  As I understand it,
>	base class subobjects are objects, and hence are covered.

Is your understanding based on reading the working paper, or discussion with
members of the committee, or is it your personal judgement of the meaning
of "subobject"? My own metaphysical perspective is that subobjects are
by definition not objects in their own right - that's why virtual functions
work the way they do. If subobjects *were* objects, then there would be
no difference between private inheritance and membership. Thus my own
personal judgement would be that (presuming nothing else is to the contrary)
base class subobjects would not be covered.

>	Does it belong in the C++ standard?  I'd say yes, given that
>	compilers will for many practical purposes be able to 
>	optimize away unneeded bytes.

I would be inclined to suspect that such opportunities would be
quite rare, given the restrictions mentioned above.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>pkt@lpi.liant.com (Scott Turner) writes:
>>	Does it govern base class subobjects?  As I understand it,
>>	base class subobjects are objects, and hence are covered.
>
>	One consequence: abstract objects can exist.
>
>	Corollary: such objects have states not accessible via
>	the contiguous storage allocated for them.
>	(via virtual function calls)

As I noted in a previous article, I don't agree with Scott Turners belief
that base class subobjects are objects. To me, these are absurd 
consequences, and thus I conclude that the assumption used in deriving them
must be flawed.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

In article <9300300.29980@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
|> 
|> As I noted in a previous article, I don't agree with Scott Turners belief
|> that base class subobjects are objects. To me, these are absurd 
|> consequences, and thus I conclude that the assumption used in deriving them
|> must be flawed.

Perhaps fjh would specify some of these "absurd consequences".  I
agree with Scott.  Base class subobjects are objects. Anything else 
would be incomprehensible to me.

Given a (pointer to) a base class subobject it is sometimes
necessary to find the containing derived class object. In the
past this conversion operation was necessary only for virtual
function call, but the semantics of C++ are best understood
by considering it a non-trivial operation.  In the future,
if RTTI is accepted, this may become an explicit user invocable
operation in some contexts.

   -- Jerry Schwarz

In article <1992Dec31.152700.21521@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
|"Same type" is a term used repeatedly in the ARM.  It has its limitations,
|but is adequate for my purpose.

"Defined by use"?  How about a "real" definition?

|"Point to distinct objects" would imply two things:
|(1) Each operand points to one object (not a function, and is not null or
|    invalid).
|(2) The objects are not identicial.  I hope to say more about this in 
|    another article.

Presumably distinct objects are not identical and objects that are not
identical are distinct? ;-)  I hope you will tell us more about this
later!

|The case I'm concerned with is limited to "objects of that type", i.e.
|each operand points to a properly constructed object of type A (which may
|be a subobject of an enclosing object constructed with a different type).

Define "subobject" and "enclosing now."

|"Compare not equal" is self-evident; the C standard uses the same kind
|of wording.  It means that the result of the operator != is 1 (TRUE) and
|the result of the operator == is 0 (FALSE).

"Compare not equal" was self-evident in C because C has a clearly stated
object model with well-defined object identity.  No such luck in C++.

In article <1992Dec31.170223.21637@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
|In article <1992Dec30.184614.5551@microsoft.com> (Jim Adcock) writes:
|> Can you define your terms for us?
|
|> "distinct objects" means what?
|It means the objects are not identical.  

Which only leaves the issue of object identity.

|I was going to say that the standard for C++ needs to spell out what it
|means for object to be identical in a better way than just by
|     1. An object is a region of storage.
|     2. A definition or a new expression reserves the storage
|        needed by the object.
|These two rules leave things much more loose than necessary when objects
|require no storage.  But note that section 1.3 of the working paper 

Lots of other things remain unclear.  If a definition or a new expressions
reserves the storage needed by an object, when and when not can other
objects use this storage? [this is a trick question ;-]

|	The constructs in a C++ program create, refer to, access, and
|	manipulate objects in memory.  Each object (except bit-fields)
|	occupies one or more contiguous bytes.

Can other objects occupy those bytes?

|I missed this a while back when enumerating the features of the ARM and
|working paper which supported
|> The desired feature is:
|>     Two pointers to the same type, which point to distinct objects
|>     of that type, compare not equal.
|This excerpt from 1.3 gives the general rule I was seeking, because
|objects can be distinguished by the storage reserved for them.

That depends on what exactly is meant by "two pointers to the same type,
which point to distinct objects of that type"

At the very least "same type" and "distinct objects" remain poorly defined
in this discussion.

|	Does it govern base class subobjects?  As I understand it,
|	base class subobjects are objects, and hence are covered.

As I understand it, base class subobjects are NOT objects, because
in the case of virtual bases this would violate the contiguous-bytes
rule.  Further it would violate the overlapping objects rule.  Also,
it would imply that deriving some class from some base class can cause
a change in behavior of an "object" of that base class, and such flies
in the face of reason [IMHO].  So I believe "base clas subobjects" are
simply distinct views on one object.  One object can have multiple
identities then, depending on how it is viewed -- as demonstrated in
my multiple-base example.

In article <1993Jan05.003819.12515@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
> In article <1992Dec31.170223.21637@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
> |In article <1992Dec30.184614.5551@microsoft.com> (Jim Adcock) writes:
> |> Can you define your terms for us?
> |
> |> "distinct objects" means what?
> |It means the objects are not identical.  
> 
> Which only leaves the issue of object identity.

Which is where I wish to leave the issue, willing to trust for the present
that objects which I wish distinct will be distinct.  This trust rests on

      1. The status of distinct objects as objects.

      2. The guarantee of 1.3 that an object occupies at least 1 byte
         of storage.

      3. The implementation's duty to reserve storage for objects.

If anyone can think of an example in which I am likely to be diappointed
and end up surprised with indistinct objects, I'd be grateful to see it.  
(Implementations which don't do their duty aren't necessarily a surprise.)

> Lots of other things remain unclear.  If a definition or a new expressions
> reserves the storage needed by an object, when and when not can other
> objects use this storage? [this is a trick question ;-]

I was responding to clarify a possible feature of pointer comparison.
To clarify everything is beyond me.

> |	The constructs in a C++ program create, refer to, access, and
> |	manipulate objects in memory.  Each object (except bit-fields)
> |	occupies one or more contiguous bytes.
> 
> Can other objects occupy those bytes?

Yes.  An _other_ object is distinct, not identical to the object with which
it shares storage.  For example, given
	int x[9];
then the bytes occupied by the objects x and x[2] overlap.

> |	Does it govern base class subobjects?  As I understand it,
> |	base class subobjects are objects, and hence are covered.
> 
> As I understand it, base class subobjects are NOT objects, because [...]
> Further it would violate the overlapping objects rule.  

What rule?

> Also, it would imply that deriving some class from some base class can cause
> a change in behavior of an "object" of that base class, and such flies
> in the face of reason [IMHO].  

If some class declares a virtual function, it's asking to be changeable.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com

jss@lucid.com (Jerry Schwarz) writes:

>In article <9300300.29980@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>|> 
>|> As I noted in a previous article, I don't agree with Scott Turners belief
>|> that base class subobjects are objects. To me, these are absurd 
>|> consequences, and thus I conclude that the assumption used in deriving them
>|> must be flawed.
>
>Perhaps fjh would specify some of these "absurd consequences".

I meant the ones that I quoted in the article I was responding to
(maxtal = John MAX Skaller):

maxtal>	One consequence: abstract objects can exist.
maxtal>
maxtal>	Corollary: such objects have states not accessible via
maxtal>	the contiguous storage allocated for them.
maxtal>	(via virtual function calls)

To me, an abstract class is a class without any actual objects of that class,
so the idea of an "abstract object" seems to be an oxymoron. Similarly, the
idea that an object can have "state" that is not stored in its "storage" seems
to make a mockery of the whole idea of "storage".

I can understand the opposing view, but it seems to me that we are just
starting from different axioms. Anyhow, this discussion does not seem to be
very fruitful.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

In article <9300812.4038@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
> maxtal>	One consequence: abstract objects can exist.
> maxtal>
> maxtal>	Corollary: such objects have states not accessible via
> maxtal>	the contiguous storage allocated for them.
> maxtal>	(via virtual function calls)
> 
> To me, an abstract class is a class without any actual objects of that class,
> so the idea of an "abstract object" seems to be an oxymoron. Similarly, the
> idea that an object can have "state" that is not stored in its "storage" seems
> to make a mockery of the whole idea of "storage".

Since John MAX Skaller was drawing inferences from my belief that base
class subobjects are objects, I want to go on record.  I agree that
"abstract objects" can exist, but the corollary does not follow.  

The easiest way to find an actual object of an abstract class is from
the point of view of a constructor for an abstract class.  What's the
type of the object pointed to by 'this'?  The type of that object is the
abstract class, no question about it.

In the corollary, John MAX Skaller is referring to a different scenario
in which the object of abstract class is a base class subobject of a
fully-constructed enclosing object.  He concludes that the state of the 
enclosing object is part of the state of the base class subobject.  The
reasoning has something to do with the additional state being accessible via
virtual function calls, but there's a big hole in it.  Virtual functions 
(and non-virtual functions) can access any number of other objects,
independent of the object for which they are called.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com