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: http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&frame=right&th=d0969f0fa2460dd4&seekm=3A2D10EE.35544D0A%40aixigo.de#link1
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...
-- 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