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
> | 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
> 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 email@example.com