Re: [boost] [multi_index] composite keys: request for advice

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

k<t,k>t,
t<k,t>k

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.

Thanks,

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