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-08-26 13:17:20


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.

-- Gaby


SG12 list run by herb.sutter at gmail.com