C++ Logo

SG12

Advanced search

Subject: Re: [ub] Justification for < not being a total order on pointers?
From: Nevin Liber (nevin_at_[hidden])
Date: 2013-10-16 10:38:39


On 16 October 2013 10:27, Gabriel Dos Reis <gdr_at_[hidden]> 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_[hidden]>  (847) 691-1404



SG12 list run by herb.sutter at gmail.com