🚀 go-pugleaf

In article <1992Dec18.204337.3084@lth.se> dag@bellman.control.lth.se (Dag Bruck) writes:
>In <comp.std.c++> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>>
>>In fact, p==q iff objects equal is unimplementable on some machines.
>>That is, even the existing ARM requirement is unworkable.
>
>No, some machines are unworkable :-).

I wont disagree with your sentiments.

However, lets consider that Unix file names are 'pointers' to files,
and that links are allowed.

Then the average program cant tell if two file names point to
the same file or not, since computing the inode number is the only
way to do that, and only super users can do this calculation.
(Imagine I'm right even if this isnt the case. Is it the case?)

Would this make such a system 'unworkable'?

The issue is whether pointers must provide any more functionality
than the ability to access an object, that is, whether object
identity can be established by pointer comparisons.
(A related issue is whether two pointers point INTO the same object,
or one points into an object the other points to)

I suggest that whole classes of software can be written that 
do not rely on the ability to test if two pointers refer
to the same object or not, other types of software require
this information.

Perhaps we can conceive two types of pointers, type 1 
provides no comparisons at all, type 2 allows equality test.

Most of the code I've written uses type 1, and most uses
of type 2 could be rewritten as type 1.

In those cases where type 2 pointers are desirable, it
seems reasonable to restrict them to pointers
to objects created directly by me, and not the operating
system.

Thus I would like to see the ARM == rewritten so the
results of == on externally derived or otherwise mangled
pointers are implementation defined.

Thus, if you write non-strictly conforming programs for
a linear address machine, I have no complaint 
when your hacks dont work on my segmented machine because
you are using 'implementation defined' features of C++.

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