NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/std/cplus/2032

Internet Message Format | 1993-01-12 | 3.5 KB

From: [e-mail] (Pablo Halpern )
Date: Mon, 11 Jan 1993 23:15:23 GMT
Subject: Re: Nested functions (was: Re: Zero-length structures and pointer comparisons)
Message-ID: <[e-mail]>
Organization: Hewlett-Packard Company
Path: sparky!uunet!usc!sdd.hp.com!hpscit.sc.hp.com!hplextra!hpcss01!hpwala!pabloh
Newsgroups: comp.std.c++
References: <[e-mail]> <BzDJHu.t2@fru <[e-mail]> <[e-mail]>
Sender: [e-mail]
Lines: 55

In article <[e-mail]>, [e-mail] (Jim Adcock) writes:
|> In article <[e-mail]> [e-mail] (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             [phone]
HP Waltham                [e-mail]

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