| -----Original Message-----
| From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On Behalf Of
| Lawrence Crowl
| Sent: Thursday, October 10, 2013 3:34 PM
| To: Nevin Liber
| Cc: ub_at_[hidden]
| Subject: Re: [ub] Justification for < not being a total order on pointers?
|
| On 10/10/13, Nevin Liber <nevin_at_[hidden]> wrote:
| > On 10 October 2013 02:36, Lawrence Crowl <Lawrence_at_[hidden]> 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