----- Mensaje original ----- De: Brian McNamara <lorgon@cc.gatech.edu> 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