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.