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