Re: [boost] Re: possible addition to operators library

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...

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de