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

Nevin Liber nevin at eviloverlord.com
Wed Oct 16 17:38:39 CEST 2013


On 16 October 2013 10:27, Gabriel Dos Reis <gdr at microsoft.com> wrote:

>
> | No, although the only sentence I can find in n3797 not requiring it
> today is in
> | iterator requirements in general 24.2.1p7: "The result of the
> application of
> | functions in the library to invalid ranges is undefined" and assuming
> that
> | operator< has to be implemented with a function so that the assertion in
> table 111
> | that "< is a total ordering relation" only holds for valid ranges.
> |
> |
> | My goal is that for two objects l and r of type T, 'std::less<T>(l, r)',
> 'std::less<>(l, r)'
> | and 'l < r' should never diverge,
>
> I am not sure expect what you mean by "diverge".  I am hoping you aren't
> arguing
> that std::less should just be a different syntax for operator<.
>

Yes, I am.  It's a long term goal. :-)  If we didn't want that, we should
never have called it less.


> That said, I am unsure how you answer "no" above squares with your goal
> as stated here.
>

How does 'less<deque<T>::iterator>()(l, r)' differ from 'less<>()(l, r)'
differ from 'l < r'?


> My own personal view (not that of chair) is that if std::less<T>(l,r) and
> "l < r" are
> both defined, then they should yield the same answer.
>

Which fails for pointers.
-- 
 Nevin ":-)" Liber  <mailto:nevin at eviloverlord.com>  (847) 691-1404
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/ub/attachments/20131016/ee06a28b/attachment.html 


More information about the ub mailing list