Hi all,
Hate to sound pushy, but I've no answer on this, were the patches ok? Would
you like me to repost them?
Or should I just drop it?
Cheers
Sam
----- Original Message -----
From: "Sam Partington" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Thursday, February 27, 2003 10:55 AM
Subject: Re: [boost] possible addition to operators library
> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
