John Spicer <jhs_at_[hidden]> writes:

| On Aug 26, 2013, at 2:17 PM, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
|
| > John Spicer <jhs_at_[hidden]> writes:
| >
| > | On Aug 26, 2013, at 12:12 PM, Nevin Liber <nevin_at_[hidden]> wrote:
| > |
| > |
| > | On 26 August 2013 11:00, Jeffrey Yasskin <jyasskin_at_[hidden]> wrote:
| > |
| > |
| > | Could someone explain why we need to allow operator<(T*) to be a
| > | non-order?
| > |
| > |
| > | It comes from C. I believe it comes from the days of segmented
| > | architectures.
| > |
| > | I do not know of any modern machines that have such architectures and have
| > | C++11 compilers for them. Whenever it comes up for discussion on various
| > | reflectors, no one has mentioned one either. I for one would like to see
| > | this restriction go away.
| > |
| > | Armchair thought: maybe we should propose a total ordering for pointers
| > | (for C++17 at this point) and see if anyone objects?
| > |
| > |
| > | All that being said, I believe Library is inconsistent in its use of
| > | operator< vs. std::less<T>, and that needs to be addressed separately.
| > | Pointers are the current poster child for the issue but user code might be
| > | specializing std::less as well.
| > | --
| > | Nevin ":-)" Liber <mailto:nevin_at_[hidden]> (847) 691-1404
| > |
| > |
| > | Given that it is possible to reinterpret_cast a pointer to a large-enough
| > | integer and being able to cast back to get the original pointer, it seems like
| > | it should be possible to support operator< on pointers.
| >
| > That reinterpret_cast is a runtime thing though. We have notions of
| > addresses at compile-time too.
| >
|
| Yes, but the point is that we already require that pointers be
| convertible to something that can be ordered, so there should not be
| any issue in just allowing that directly.
|
| John.

Indeed, I am trying to make sure that we understand the implications of
available design decisions. For example, historically, we have
refrained from endowing operator< with meaning that was perceived to be
"canonical" -- of couse, operator< on pointer is one; another is
operator< on std::complex<T>.

(My role as chair isn't to be one-sided, but to make sure that all
sides are considered, and possibly argue a position I do not necessarily
agree with, just to make sure we considered relevant aspects.)

-- Gaby