Re: [boost] possible addition to operators library

From: Sam Partington (Sam.Partington_at_[hidden])
Date: 2003-02-27 05:55:27

Daniel Frey wrote:
>>
>> Daniel Frey wrote:
> No problem. IIRC it was Peter Dimov who came up with the safe-bool
> idiom first. At least I saw it first from him. Another way which
> works but results in worse error messages is this:
>
> template <class T, class B = ::boost::detail::empty_base>
> struct bool_testable : B
> {
> private:
>   operator int() const;
>
> public:
>   operator bool() const
>   {
>     return !!static_cast< T& >( *this );
>   }
> };
>
> It should be a more efficient implementation for most of the points
> Dave mentioned and it should also work in all cases (allowing the use
> as a bool, int is private, thus not accessible and other conversions,
> e.g. to 'long' are ambiguous. The drawback is, that the error
> messages are not as clear and obvious as for Peter's idiom.

Well we'll stick with Peter's model then.  I had figured it was Peter,
someone let me know if it wasn't.

Sam Partington (me!) wrote:
> Is there another alternative to this?  How about this:
>
>   typedef void (bool_testable<T,B>::*unspecified_bool_type)() const;
>   operator unspecified_bool_type() const
>   {
>    return !static_cast<const T&>(*this) ? 0 :
> reinterpret_cast<unspecified_bool_type>(&bool_testable<T,B>::operator
> unspecified_bool_type);
>   }
>
>
> Does this have any issues that I can't see?   Ideally we could avoid
> the reinterpret_cast, but how do you express the type of a
> user-defined conversion operator for the type you're trying to
> express? Beats me!

I was hoping for a response to this, but I know we're all busy, so I'll take
the silence to mean that noone has any serious objections.  I know lots of
you will see the reinterpret_cast and start shouting "non-portable" but in
this case all its doing is casting the return type of the function pointer.
Also we're not going to use the pointer other than a compare to zero, so
providing there are no compilers that would reinterpret_cast to a zero, I
don't see a problem.

This is my preferred solution for now, as it avoids a lot of the overhead
problems that have worried some of you.

I've attached the patches, including docs and test.

Sam