>> Unfortunately I don't understand this. It can go in the >> documentation, with the work around to be : >> if (!!a && ...) >> or >> if (a) >> if (...) > > Of course. But I was hoping for a work-around at the library-side, not > at the user's side. What exactly are the overloads that the VC thinks > might match? Or what type does it try to cast the expression to > (instead > of bool)? Yes, library side fix would be much nicer. But I'm stuck on this. The compiler is _really_ helpful here:
z:\test.cpp(37) : error C2593: 'operator &&' is ambiguous thats it! The compiler docs suggest to resolve the ambiguity you explicity cast one or both of the arguments of the operator. But if (static_cast<bool>(a) && ... is even more of a mouthful. At least there's still no danger of passive errors. >> Finally, if we choose this route, this means that we can take the >> approach of providing operator! and a private operator >> some_number_type() while the user provides operator bool. This is >> more semantically correct in my opinion, anyone have any problems >> with this? >> >> Oh, I should have patches posted very soon. > > Fine. Remember that the name should probably change to reflect the > "corrected" semantics. Something like 'bool_negatable'? I don't think it does. Actually I always felt that bool_testable was wrong. After all equality_comparable provides the inequality test. And dereferenceable provides ->. So bool_testable should provide the opposite of bool testable. i.e. operator!. If you get me :-) > But then, there is still some slight illogic here: We provide > operator!, > but the protector is for operator bool. Two orthogonal concepts. Would > it make sense to separate them? If so, will 'bool_protector' have any > value? Those people not aware of the problem of providing operator > bool() will not use it, those that are aware will use Peter's > safe-bool-idiom when appropriate as it gives better error messages. > And > where safe-bool is not applicable, you don't need a protector anyway > AFAICS. Hm... thoughts? I guess it comes down to the same sort of style as noncopyable. The people who really need it are those that aren't even aware there is a problem. Still, I am seeing colleagues who almost never make use of boost make use of noncopyable regularly because it is self documenting, I guess thats what we can hope for. As for whether we should seperate the two concepts, perhaps, but I don't any occasions when I would want bool_testable and not bool_protector. Therefore if we were to seperate them I would like bool_testable to derive from bool_protector bool_protector - prevents accidental conversions to int for classes with operator bool bool_testable - provides bool operator!(const T&) AND bool_protector template<class T, class B = ::boost::detail::empty_base> struct bool_testable : bool_protector<T, B > {...}; But I do ask myself, is this a likely use-scenario? Sam _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost