Boost logo

Boost :

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 )
       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_at_[hidden], web:

Boost list run by bdawes at, gregod at, cpdaniel at, john at