Boost logo

Boost :

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.
> 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

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