From: Matthew Austern (austern_at_[hidden])
Date: 2000-11-27 12:13:06
Jeremy Siek wrote:
> Hi John,
> 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.
> So does anyone know how to either:
> 1) create an alternate definition of strict weak ordering
> that only uses value_type < T.
> 2) create some alternate requirement (not strict weak ordering)
> that is enough to ensure lower_bound() will work.
> I'm no expert on sorting, so I don't know if 1) or 2) is possible,
> or what form they would take.
See the writeup for library issue 270, in
There was some discussion of both options. There's a
preliminary suggestion for what a relaxed requirement
(in #2) might look like.
However, when this issue was discussed in Toronto, there
was some opposition to having this sort of relaxed requirement.
Most people seemed to think it was inappropriate to allow a
function object that had an operator()(value_type, T) and
that didn't have an operator()(value_type, value_type).
There was more discussion of what the requirements for a
function object with both overloads might look like.
Among other things, note that the standard talks about
'value_type < T' for lower_bound, 'T < value_type' for
upper_bound, and both expressions for equal_range.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk