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: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
