RE: [boost] Re: safe_bool alternative?

From: Sam Partington (sam.partington_at_[hidden])
Date: 2003-11-24 12:16:00

boost-bounces_at_[hidden] <> wrote:
> Douglas Gregor wrote:
>> The problem is that is_convertible<no_integers_except_bool,
>> int>::value results in a compile-time error instead of being false.
>> This is why I don't believe bool_testable should have gone into the
>> operators library, because it looks like it's safe and useful but
>> can cause annoying problems. 
> 
> I'm concerned about this issue, too. It seems that
> bool_testable isn't
> the small and side-effect-free enhancement we hoped. During it's
> development, I think the above problem wasn't raised. We reached a
> consensus that it should be added. Now that we know about the problem
> above, the question is whether we should remove bool_testable or take
> some other action. 

>> But alas, we don't review changes to libraries after they're
>> accepted. 

No it wasn't reviewed in a formal way.  But most changes or additions are
discussed in a public forum - i.e. this list.  

I see two problems with the current implementation of bool_testable :

1/ The is_convertible problem above.

2/ Binary logical expressions with a bool_testable derived class on either
side are ambgious in VC6, VC7, and VC7.1.  Thus:
        struct A : img::bool_testable<A>
        {
                operator bool() const;
        };

        A a;
        bool b = a && 1; // "operator && is ambiguous"
        bool c = 1 && a; // "operator && is ambiguous"

It seems that VC is looking for conversions to fit a function signature of
bool (int, int).  Whereas most compilers look for bool (bool, bool).  Which
is correct according the standard is not clear as it merely states  

"""
5.14 Logical AND operator
        ... The operands are both implicitly converted to type bool... 
        ... The result is a bool...
"""

Which implies to me that the above expressions should be well formed, but is
not explicit, and I am no expert.

Can we work around these problems?  The original ptr-to-member design avoids
both of them, but introduces a problem if the user provides their own
integer conversion operators.  

Can we use enable_if or is_convertible to provide a best fit solution for
the class in question?

My own feeling is that even if we can't find a solution to those two
problems then bool_testable is still a sufficiently useful addition to the
operators library for it to remain.  I think it seems an obvious omission
from the operators library - providing all operators except bool comparison.
Of course this problem should be reflected in the documentation if we cannot
solve it.

Sam
******************
This e-mail has been sent from Imagination Technologies Limited.   PowerVR, Metagence, Ensigma 
and PURE Digital are divisions of Imagination Technologies Limited.

The information contained in this e-mail, including any attachment, is confidential and may be
legally privileged.  It is intended solely for the addressee(s) and access to this e-mail by
anyone else is unauthorised.  If you are not the intended recipient, any disclosure, copying or
distribution or use of the information contained in this e-mail, is prohibited and may be unlawful.
If you have received this e-mail in error, please notify the sender by return e-mail and then
delete it from your system.

Internet communications cannot be guaranteed to be secure, error or virus-free.  The sender does
not accept liability for any errors or omissions which arise as a result.

Any views expressed in this message are those of the author, except where the author specifies and,
with authority, states them to be the views of Imagination Technologies Ltd.