$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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