I think I agree, we want to provide as little restrictions as possible. Also seems to me that anyone who declares a global template operator! deserves some problems!
So, now with David's suggestion, I've attached what I propose.
I've tested to a small extent on MSVC6 and gcc 2.95, which are all the
compilers I have access to now.
(First time I've used a patch file so apologies if I've messed it up)
Sam
PS Did anyone who uses OE-Quote notice what a mess it made of the wrapping,
interpreting
B>:: as three seperate reply inserts? and so miss out the B, and substitute
> > >. ;-) Great program 99% of the time though.
David Abrahams wrote:
> "Sam Partington" <[EMAIL PROTECTED]> writes:
>
>> I thought of this too, but this limits the user to using a member
>> based operator!. So I couldn't do this :
>>
>> class A : public boost::bool_testable<A>
>> {
>> public:
>> int get();
>> };
>>
>> bool operator!(const A& a)
>> {
>> return a.get() == 0;
>> }
>>
>> Of course I've never actually wanted to do that, so its maybe not a
>> problem. After all the conversion operator itself has to be a
>> member, so it probably isn't much of a restriction at all.
>
> Ahem. The operators library is *all about* defining free function
> operators. I don't think you should introduce a dependence on being
> a member function.
>
>> Then again, how much does the safe_bool_conversion function cost?
>
> More than I'd like. I'd prefer to use a single data member pointer,
> since it's likely to be more efficient.
>
> struct safe_bool
> {
> #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS
> private:
> template <class T, class B> friend class bool_testable;
> #endif
> int x;
> typedef int safe_bool::*type;
> };
bool_testable.patch
Description: Binary data
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
