Re: [boost] possible addition to operators library

From: Sam Partington (Sam.Partington_at_[hidden])
Date: 2003-03-07 05:46:24

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" <Sam.Partington_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
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