Re: [boost] Re: safe_bool alternative?

From: Douglas Gregor (gregod_at_[hidden])
Date: 2003-11-24 13:54:30

On Monday 24 November 2003 12:16 pm, Sam Partington wrote:
> 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 do apologize for not raising my concern back when this was originally 
discussed. In my defense, I was moving across the country on the day 
bool_testable was committed to CVS :)

> 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:
[snip]

I wouldn't hold this against bool_testable; it seems obvious to me that VC is 
wrong here.

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

There is no perfect solution, I'm afraid.

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

Other than hacking is_convertible to first perform an is_base_and_derived 
check to deal specifically with bool_testable, I don't see a good way around 
this.

> 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

My concern with bool_testable is that we're giving users an easy solution to a 
problem, but it doesn't completely work. Which solution should they choose? I 
personally will only use the ptr-to-member design because it works completely 
and I can deal with the operator int() issue. The difference between the 
operator int() problem with the ptr-to-member idiom and the is_convertible 
problem with bool_testable is that in the former case the user needs to do 
something (wrong) to make it fail; in the former case, the user needs to do 
extra work to make it pass. Assuming we can't find a clean is_convertible 
workaround, at what point is it just easier to follow the ptr-to-member 
idiom?

Another (minor?) issue with bool_testable: either the documentation (or, 
better yet, the code) should note/enforce that bool_testable types should 
have operator== or operator!= unless the user explicitly creates them (see, 
e.g., the "poisoned" operator== and operator!= in the Function library). I'm 
not sure if this would suffice:

template<typename T1, typename B1, typename T2, typename B2>
  void operator==(const bool_testable<T1, B1>&, const bool_testable<T2, B2>&);
template<typename T1, typename B1, typename T2, typename B2>
  void operator!=(const bool_testable<T1, B1>&, const bool_testable<T2, B2>&);

        Doug