On Thu, Oct 17, 2013 at 12:41 PM, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> James Dennett <jdennett_at_[hidden]> writes:
>
> | 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,
>
> How do you arrive to this conclusion?

One arrives at a conclusion of "nothing guarantees" by failing to find
a guarantee. If you want to dispute this conclusion, you should point
at a guarantee.

> | 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
> | _______________________________________________
> | ub mailing list
> | ub_at_[hidden]
> | http://www.open-std.org/mailman/listinfo/ub
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub