[ub] Justification for < not being a total order on pointers?

Gabriel Dos Reis gdr at microsoft.com
Thu Oct 10 22:39:37 CEST 2013


| -----Original Message-----
| From: ub-bounces at open-std.org [mailto:ub-bounces at open-std.org] On Behalf Of
| Lawrence Crowl
| Sent: Thursday, October 10, 2013 3:34 PM
| To: Nevin Liber
| Cc: ub at open-std.org
| Subject: Re: [ub] Justification for < not being a total order on pointers?
| 
| On 10/10/13, Nevin Liber <nevin at eviloverlord.com> wrote:
| > On 10 October 2013 02:36, Lawrence Crowl <Lawrence at crowl.org> wrote:
| >> The problem is that if you need to represent an object with more than
| >> one segment (as was necessary for arrays > 64 kB on x86) then
| >> requiring a total order within an array places a consistency requirement
| >> on computing a total order between arrays.
| >
| > Didn't that issue already exist in C++98 (at least with respect to
| > std::less)?
| 
| I think so, but that probably implies that the library hasn't been implemented
| on the full range of machines allowed by the base language.
| 
| At this point, I think we need to ask if we really do want to support machines
| with small segments.  Does anyone know of any current such machines?

That is a good question that we should consider.

Another aspect to consider is that, even though this restriction
was originally motivated by segmented architecture, it is also useful
for other things and implementation techniques (including compacting
GCs).  One question is whether we believe we want to forgo implementations
or implementation techniques that might profit from the current restriction.

I think this question should be considered independently of whether we 
still want to support segmented architectures, because that may affect
the form of the outcome.

-- Gaby



More information about the ub mailing list