RE: [boost] Re: safe_bool alternative?

From: Sam Partington (sam.partington_at_[hidden])
Date: 2003-11-25 10:36:12

Daniel Frey <mailto:daniel.frey_at_[hidden]> wrote:
(snip)
> But instead of writing it down all here, this is probably
> what should go
> into the operators library's documentation. Or in a separate document.
> Peter? In this case the library would provide documentation, knowledge
> and background information, plus a comparison to
> alternatives. It cannot
> offer code to include, only help to implement Peter's
> technique in the
> right way with the right workarounds. In that sense, we could
> also say
> that the technique is already used in other parts of boost and IMHO a
> fast-track review is therefore justified. It's also a special
> situation as we are not discussing the inclusion of new code, but the
> removal of
> existing code from the CVS.

Documentation of Peters idiom in a very limited form, including why it is
not suitable in a generic case is available in the rationale part of the
bool_testable notes :

http://boost-consulting.com/boost/libs/utility/operators.htm#safe_bool_note

This could be extended or moved to a separate document.

David Abrahams <mailto:dave_at_[hidden]> wrote:
> It seems to me it should be possible to make bool_testable use
> Peter's idiom.  Am I missing something?

That was the original suggestion : 
http://lists.boost.org/MailArchives/boost/msg44416.php

but as people pointed out (Daniel I think) in the case of there being a user
defined conversion operator to integral type, the bool conversion is never
called.

I've been playing with the idea of selecting from either implementation as
suitable :

template <class T, class B = ::boost::detail::empty_base>
struct bool_testable : B
{
        operator bool() const  
        { 
                return !!static_cast<const T&>(*this);    
        }
private:
        typedef signed char private_number_type;
        operator private_number_type() const;
};

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!;

        }
};

template<class T1, class T2, bool value> 
        class select_bool_impl : public T1
        {};

template<class T1, class T2> 
        class select_bool_impl<T1, T2, false> : public T2
        {};

template<class T, class B = ::boost::detail::empty_base> 
        class the_bool_testable :
                public select_bool_impl<safe_bool<T, B>, 
                                                bool_testable<T, B>,
                                                boost::is_convertible<T,
int>::value
						>
{
};

The idea being that if the derived class has a user-defined conversion
operator to use the private number type, otherwise to use Peter's safe-bool
idiom.  I thought this would do the trick, but when I tried the following : 

struct Test1 : the_bool_testable<Test1>
{
        bool operator!() const;
};
BOOST_STATIC_ASSERT((boost::is_base_and_derived<safe_bool<Test1>, Test1
>::value));
// (^^ this fails ^^ )

struct Test2 : the_bool_testable<Test2>
{
        bool operator!() const;
        operator int() const;
};
BOOST_STATIC_ASSERT((boost::is_base_and_derived<bool_testable<Test2>,
Test2>::value));

to check that the correct implementation was being instantiated, I realised
that is_convertible is always returning  true in this situation.  Presumably
because it is finding the bool conversion?  Any help here appreciated, or if
you think I'm barking up the wrong tree completely, please let me know.

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.