RE: [boost] Another safe_bool alternative?

From: Douglas Paul Gregor (gregod_at_[hidden])
Date: 2003-11-28 00:56:28

On Thu, 27 Nov 2003, Sam Partington wrote:
> template <class T, class B = ::boost::detail::empty_base>
> 	struct safe_bool : B
> {
> 	typedef bool (T::*safe_bool_type)() const;
>
> 	operator safe_bool_type() const  { return !static_cast<const
> T&>(*this) ? 0 :  &T::operator!;    }
> private:
> 	bool operator!=(const safe_bool<T>& rhs) const;
> 	bool operator==(const safe_bool<T>& rhs) const;
> };

I'd be fine with this, but we should be using a member data pointer
instead of a member function pointer.

> But this still does not solve the problem of what happens if the user
> provides their own conversion operator.  (See Rationale section at
> http://boost-consulting.com/boost/libs/utility/operators.htm#safe_bool_note
> )
>
> Since we can't select an appropiate instantiation at the derivation point.
> Can we at least the warn the user if they are using an inappropiate :
>
> safe_bool()
> {
>   // if this line fails to compile, consider using bool_testable
>   // see documentation at http://....
>   BOOST_STATIC_ASSERT(!(
>     boost::is_convertible<T, char>::value ||
>     boost::is_convertible<T, short>::value ||
>    // ...
>   ));
> }

Yep, that's good.
> Then if the type is convertible to an integral type, then the user is told
> that the implementation is inappropiate and redirected to an alternative
> implementation.  Similarly, bool_testable could have the corresponding
> check.

I'd rather not have bool_testable at all, personally. The above is I think
the right way to formulate the safe_bool idiom.

        Doug