$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: John E. Potter (jpotter_at_[hidden])
Date: 2000-11-25 19:47:53
On Sat, 25 Nov 2000, Jeremy Siek wrote:
> Well, if we really want to minimize the requirements for lower_bound
> (which I agree in general is a very good idea) then we have to define
> strict weak ordering in a much different way, or not require strict weak
> ordering for lower_bound() and require something else.
> 
> The definition of strict weak ordering in 25.3 makes lots of uses of T < T
> and value_type < value_type.
Yes, and it makes sense for sorting, but maybe not for searching.
> So does anyone know how to either:
> 
> 1) create an alternate definition of strict weak ordering
>  that only uses value_type < T.
The definition is used to define the order which the range must
satisfy.  Value_type < value_type is required for that.  The
assumption for the binary search algorithms is that the range
is ordered.  I don't think that anyone wants a run time verification
of that order every time that lower_bound is called.  If not, there
is no need for value_type < value_type in lower_bound.
> 2) create some alternate requirement (not strict weak ordering)
>   that is enough to ensure lower_bound() will work.
The requirement is there, I just don't think that it is testable.
> I'm no expert on sorting, so I don't know if 1) or 2) is possible,
> or what form they would take.
Maybe I just don't understand the problem.  How about an example?
struct S { int a; int b; };
struct LessS { bool operator() (S const& lhs, S const& rhs) {
      return lhs.a < rhs.a; };
struct FinderS { bool operator() (S const& lhs, int rhs) {
      return lhs.a < rhs; };
vector S v;
// fill v
sort(v.begin(), v.end(), LessS());
cout << lower_bound(v.begin(), v.end(), 42, FinderS())->b;
This will work on all implementations which I have seen.  Note also
that operator< could have been defined and used for either or both.
The point is that the operator used for lower_bound need not be the
same operator that was used for sort.  If I were to compile this
with some strange library which used other operations, I would
get a compile error.  If I compile it with a reasonable library
which only uses the needed and supplied operator, I would not
like to see some silly concept violation error.
If I replace < with > in FinderS, the algorithm will not work
and no concept check can detect it.  I guess that I just don't
see the point.  The testable requirements are the operations
that the algorithm uses.  The compiler checks them.
John