[ub] Justification for < not being a total order on pointers?

Gabriel Dos Reis gdr at axiomatics.org
Mon Aug 26 20:17:20 CEST 2013


John Spicer <jhs at edg.com> writes:

| On Aug 26, 2013, at 12:12 PM, Nevin Liber <nevin at eviloverlord.com> wrote:
| 
| 
|     On 26 August 2013 11:00, Jeffrey Yasskin <jyasskin at google.com> 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 eviloverlord.com>  (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



More information about the ub mailing list