🚀 go-pugleaf

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"

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.