Boost logo

Boost :

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2004-04-25 13:18:00

----- Mensaje original -----
De: Brian McNamara <lorgon_at_[hidden]>
Fecha: Domingo, Abril 25, 2004 6:05 am
Asunto: Re: [boost] [multi_index] composite keys: request for advice

> On Sun, Apr 25, 2004 at 03:54:31AM +0200, JOAQUIN LOPEZ MU?Z wrote:
> > > that if you call these two object "k" and "t" (key and tuple),
> > > then you should have
> > > k < t false
> > > t < k false
> > > t == k does not compile
> > > That's just my quick hunch based on what I've quoted above; I
> haven't> > considered what consequences it has for the library,
> but that's my
> > > intuitive notion of how tuples as "partial keys" ought to work.
> >
> > I guess I agree with you, but I wanted to bring this
> > in to the list to gather some opinions. Following your
> > approach, what should we do with
> >
> > k <= t
> > t <= k
> >
> > The options are:
> >
> > a. they hold true
> > b. they do not compile
> >
> > I don't have any strong argument in favor of any option.
> If there are other std:: or boost:: types which model the
> StrictWeakOrdering concept (without having total orders), I would see
> what they do and follow their lead.
> If not, I would make the "<=" operators not compile, since
> k <= t
> can always be rewritten by clients as
> !(t < k)
> and the narrower interface reduces the likelihood of someone
> mistakenlygetting the impression that there's a total ordering
> here (IMO).

I've scanned Boost and results are not conclusive. At
least one class (shared_ptr) does define operator< and
does not define <=, >= etc. so I'm not alone.
I think I'll follow your advice and be conservative
here (we'll always have time to extend this; the other way
around is more problematic). So, the rules I'll stick with are:

1. if k and t have the same number of elements then

k==t, k!=t, k<t, k>t, k<=t, k>=t,
t==k, t!=k, t<k, t>k, t<=k, t>=k,

are all defined and follow the lexicographical convention.
2. If k and t have different number of elements, then


are the only operators defined and follow the "clipping rule"
(compare lexicographically taking the minimum of the lengths
of the operands.)

3. std::less and std::greater are specialized to accept
comparison between composite_key results and tuples,
according to the previous definition. No other std
comparison object is specialized.

If nobody finds a problem with this, these are the rules
that'll go into the implementation of composite_key.


Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Boost list run by bdawes at, gregod at, cpdaniel at, john at