[boost] Re: lexicographic: review request?

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-08-24 04:30:49

Daryle Walker wrote:
> On Saturday, August 23, 2003, at 11:21 AM, Daniel Frey wrote:
> 
>> a) Short-circuiting
>> b) Unnamed functions
>>
> Short-circuiting can only be done via compiler magic with the built-in 
> operator&& and operator||, so there's no way it can be added to 
> user-defined routines.  Note that each step of the lexicographic

macros and ?: can - as I showed - do short-circuiting, too. User-defined 
functions - as you said - can't.

> comparison has a result, and that later steps are only evaluated if the 
> previous step didn't give a result of equivalence (well, the comparison 
> is skipped; each argument still has to be evaluated).  You can also 

Evaluation of arguments is IMO the problem.

> manually check each intermediate result and code out other checks (with 
> "if" statements), which would skip unnecessary evaluations of later 
> components.

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

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

> I don't think you can (re#)define a keyword.

You can. But I admit that it's a stupid idea to do it, which is why I 
don't honestly propose to use true()/false()-macros :)

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de