From: Sam Partington (Sam.Partington_at_[hidden])
Date: 2003-03-12 12:52:22
>> Unfortunately I don't understand this. It can go in the
>> documentation, with the work around to be :
>> if (!!a && ...)
>> 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
> 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
>> 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
> 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.
> 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
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 - prevents accidental conversions to int for classes with
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk