🚀 go-pugleaf

In article <1993Jan06.193256.6590@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
|> In article <4048@hpwala.wal.hp.com> pabloh@hpwala.wal.hp.com (Pablo Halpern ) writes:
|> |Absolute orderings are a slightly different matter.  In the case of < and
|> |>, one might expect a significant performance improvement if the pointers
|> |are assumed to point into the same array, since the segment part can be
|> |ignored even for far pointers.  A ptrcmp() function might be worthwhile and
|> |should present no special implementation problems for segmented
|> |architectures.  However, systems (like the lisp machine) where pointers
|> |change behind the program's back DO present a problem since the
|> |bit-pattern-based ordering could change even if the equality/inequality
|> |property does not change.  This would argue against *requiring* a ptrcmp()
|> |function.
|> 
|> Except some OS's using segmented architectures implement movable segments, 
|> in which case the problem becomes the same as lisp machines --
|> "pointers change behind the programmers back"

Perhaps, but not usually.  Part of the power of segments is to be able to
change the physical location of a segment without changing pointers to that
segment.  Never the less, the problem DOES exist on some architectures,
both segmented and not.

|> 
|> My claim is that in either of these cases the pointers *aren't* changing --
|> they still point at the same objects.  What is changing is the underlying
|> implementation of the pointer, which is an implementation issue not
|> a language issue.  Casting pointers to and from int remains as always
|> implementation dependent.  The only issue in question is whether we
|> should introduce a new requirement on OS's that the OS must maintain
|> a total ordering on their objects.  Clearly IMHO this would represent
|> a stumbling block to many OS's, such a the lisp machines, movable segment
|> OS's and OO databases.  Making such a new requirement on C++ would make
|> C++ not reasonably portable to these systems.  The question then is
|> whether or not the standard C++ language should exist on such machines.

Exactly.  Maintaining a total ordering of objects based on pointers to
those objects is not resonable in some OS's.  IMHO, the need for a total
ordering of pointers is not as compelling as the ability to implement the
C++ standard on the widest variety of architectures.  A function like
ptrcmp() should fall into the "common extentions" catagory.  Most
systems could implement this function using a varient bit-by-bit
comparison.  Systems that patch pointers in running code could not
implement this function.

-- 

- Pablo

------------------------------------------------------------------------
Pablo Halpern             (617) 290-3542
HP Waltham                pabloh@hpwarq.wal.hp.com

I am self-employed, so my opinions *do* reflect those of my employer.
However, they may not reflect the opinions of my client.
------------------------------------------------------------------------