Boost logo

Boost :

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-03-08 05:24:29

Daniel Frey wrote:
> One problem I just found with your implementation (and thus with Peter's
> idiom in general) is, that is doesn't provide an operator bool(). This

This sounds too hard. Of course it's not a problem where Peter used it
as there obviously is no other operator int() or something. The problem
only occurs when you try to create a generic component that should work
with all classes.

> [...]
> int(). Several options come to mind:
> - Document it that the class T of bool_testable< T > shall not have any
> other operators that might conflict.
> - Use the above alternative implementation I showed. It is not as nice as
> yours/Peter's wrt error-messages, but it works as expected.
> - Convince the standard committee that "explicit operator bool" is needed
> :) See:

Another alternative would be to create a selector which switches from
the safe-bool-idiom to a real operator bool when appropriate. This would
involve type-traits I guess and as a start we could try to detect
convertability to bool of the class T. But this is IMHO not sufficient,
as T might have operator int() and operator long(), so the detection
will fail (ambiguous). Although this alternative would lead to the best
result, I don't have a clever idea how to achieve that...

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