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

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2004-04-24 20:54:31

----- Mensaje original -----
[...] 
> > composite_key</* as before*> ck;
> > ck(record(1,2,3))<=make_tuple(1,2); // yields true
> > make_tuple(1,2)<=ck(record(1,2,3)); // yields true
> > 
> > So far, this is all IMHO perfectly consistent,
> > but the following design decision is not 
> > obvious to me: given the previous, what should
> > be the result of
> > 
> > ck(record(1,2,3))==make_tuple(1,2); // true or false?
> > 
> > As these two objects are neither greater than the
> > other, at least they are *equivalent*, but maybe
> > allowing operator== to return true is too much.
> 
> It sounds to me like you have a partial ordering or a strict weak
> ordering, but not a total ordering.  
>   http://www.sgi.com/tech/stl/StrictWeakOrdering.html
> That is, these two objects:
>   ck(record(1,2,3))    make_tuple(1,2)
> are in the same equivalence class, but they are not equal.  My 
> hunch is
> 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.

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