[boost] Re: lexicographic: review request?

From: Jan Langer (jan_at_[hidden])
Date: 2003-08-24 11:49:11

Daniel Frey wrote:
> The point is, that Jan proposed to add something which has a hidden 
> overhead and I'm not sure it's a good idea. Instead of nested 
> if-else-cascades, the user could also write:
> 
> bool operator<( const person& lhs, const person& rhs )
> {
>    return
>       lhs.lastname != rhs.lastname ? lhs.lastname < rhs.lastname :
>       lhs.firstname != rhs.firstname ? lhs.firstname < rhs.firstname :
>       lhs.age < rhs.age;
> }
> 
> This scheme is easy to remember, (IMHO) easy to read, doesn't have 
> nested if's and it has short-circuiting. It's only cost which may be 
> removed by Jan's proposal is that it removes the redundancy in typing. A 
> per line-macro could do that without further problems, but I won't use 

could you write this macro? i dont see a way to end the recursion.

> it anyway. Sometimes I prefer to see the real code, hiding something 
> needs a better rationale IMO. So we need some very convincing arguments 
> for a new utility if we have to remove the short-circuiting.

you are right. but i think you think of rather complicated use cases 
where the arguments itself may involve some code like arithmetic stuff 
or function calls. but its senseless to discuss it, because some people 
probably like it and some not.

on the other hand i should also add a section to the documentation to 
explain the drawbacks of using this class.

>>> Also, you might not want to define operator<. Sometimes, you just 
>>> need it in one place, e.g. std::sort( v.begin(), v.end(), /*HERE*/ );
>>
>> Maybe Boost.Lamda or Boost.MPL can be used?
> 
> Sure, but if the syntax becomes too complicated, users will stick with 
> the if-else-way. Lambda and MPL might be too complicated for such a 
> small helper. I think the proposed helper was meant to have an easy 
> syntax, but maybe I'm reading Jan's proposal the wrong way.

no. you are right. as i wrote in another posting, lambda is IMHO too 
complicated for most use cases. because often one does not apply the 
comparison in a certain order to all elements of a struct or something 
of similar regular structure.

jan

-- 
jan langer ... jan_at_[hidden]
"pi ist genau drei"