C++ Logo

SG12

Advanced search

Subject: Re: [ub] Justification for < not being a total order on pointers?
From: James Dennett (jdennett_at_[hidden])
Date: 2013-10-17 14:38:05


On Thu, Oct 17, 2013 at 8:19 AM, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> Nevin Liber <nevin_at_[hidden]> writes:
>
> | But, even if segmented architectures, unlikely though it is, do come back, the
> | ordering problem still has to be addressed, as std::less<T*> is required to
> | totally order pointers. I just want operator< to be an alternate spelling for
> | that property.
>
> I will repeat this again: std::less<T*> is absolutely not a problem,
> because this
>
> return intptr_t(p) < intptr_t(q);
>
> is valid and portable definition that requires no other special handling.

I think it's not useful though; nothing guarantees that p == q =>
intptr_t(p) ==intptr_t(q), so far as I know, much less that p<q =>
intptr_t(p) < intptr_t(q). (I'd be happy to be wrong.) (In other
words, it's not suitable as a portable definition of std::less<T*>.)

Or do we require, somehow, the conversion to an integral type to
normalize segmented addresses, rather than just concatenating them
(e.g., imagine a platform where the effective address is
(hiword<<16)+loword, which permits many representations of the same
address. Comparisons on such pointers need to deal with that
equivalence relation there, but converting to intptr_t by just taking
(hiword<<32)+loword appears valid.

-- James


SG12 list run by herb.sutter at gmail.com