Nevin Liber <nevin_at_[hidden]> writes:

| 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.

in that case, the real issue isn't 'undefined behavior with operator< on
pointers'.

| 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'?

That does not help me understand your answer to my previous question and
your new question.

| 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.

"fails" in which sense? It is certainly true in the current standards
these expressions are both defined when 'l' and 'r' are related
addresses (relative to the same object), which was exactly my point.

-- Gaby