C++ Logo

SG12

Advanced search

Subject: Re: [ub] Justification for < not being a total order on pointers?
From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2013-10-17 14:41:18


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?

| 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


SG12 list run by herb.sutter at gmail.com