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

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