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: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@[...].de, web: http://www.aixigo.de


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost