|
Boost : |
From: Matthew Austern (austern_at_[hidden])
Date: 2000-11-28 16:29:06
"John E. Potter" wrote:
> Thanks for the issue and the pointer. Note that this issue applies
> equally to the functions without a compare object.
>
> struct S { int a; int b; };
> struct CompS {
> bool operator() (S lhs, S rhs) {
> return lhs.a < rhs.a;
> }
> };
> bool operator< (S lhs, int rhs) { return lhs.a < rhs; }
>
> vector<S> v;
> // fill v
> sort(v.begin(), v.end(), CompS());
> cout << lower_bound(v.begin(), v.end(), 42)->b << endl;
>
> Is this program ill-formed because there is no operator<(S, S)?
I would say that hasn't yet been settled. I didn't ask for
a show of hands at the Toronto meeting, because I don't
think the issues have been clarified yet, but my impression
of LWG sentiment is that most people are leaning towards
answering "yes".
The arguments in favor of a "yes" answer are:
- Although the wording is sloppy, I think the only
reasonable reading of 25.3, paragraphs 1-5, are
that they apply both to an operator< and to an
explicitly provided function object. So lower_bound
is required to take a strict weak ordering, and the
strict weak ordering requirements involve comparing
two objects of the same type.
- 25.3.3 says that when you use lower_bound, the sequence
you're searching must be ordered according to the same
comparison that you're (explicitly or implicitly) passing
to lower_bound. In this example you're not doing that:
the sequence is sorted by CompS, and the search
uses operator<(S, int).
- The standard gives no guidance about the requirements on
a mixed-type comparison function. If mixed-type
comparison functions are to be allowed, then clearly
the standard has to say what they're supposed to look
like.
My opinion (not univerally shared) is that the standard is
defective, but that the most sensible reading of the status
quo is that a mixed comparison function like CompS is
currently illegal. I don't have a strong opinion about
whether or not it should be legal.
--Matt
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk