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
> operator int() const;
> 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 :
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk