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
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 :)
-- 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: http://www.aixigo.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk