Hi all,
Sorry I've been off air for a bit. I'll try to answer as much as I can in
this email.
Daniel Frey wrote:
> I also think it would be fair to mention Dave as a contributor, too,
> as he provided the way to reduce the overhead.
Of course, that bit was still there from the first time through, also
whoever came up with the original "unspecified-bool-type" idiom needs
acknowledged as well. No offence intended, merely laziness. Sorry.
David Abrahams wrote:
> "Sam Partington" <[EMAIL PROTECTED]> writes:
>> Also seems to me that anyone who declares a global template operator!
>> deserves some problems!
> I don't know why you think so.
Well, I don't mean that they deserve to be stoned to death or anything! But
they are going to be seeing some strange things anyway. I don't think us
providing with them another operator is going to cause them any more issues.
>> 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)
>
> It's very nice, but you left out the most-important parts: patches
> for the docs and testsuite.
How did I know someone would pull me up on that :-) I'm working on them, I
just need to get a handle on the test suite first. I was fairly sure that
the code patch was going to be enough to get us discussing for now.
Douglas Paul Gregor wrote:
> myclass m;
> yourclass y;
>
> if (m == y) {
> // what's this mean?
> }
>
> This is the reason boost::function has poisoned operator== and
> operator!=.
Doesn't this require two user defined conversions, which stops this from
being possible? However I agree we should avoid possible problems like
this. The idea behind "unspecified-bool-type" is to return an obscure type
that can't be accidentally used where not expected - so I would say make it
as obscure as possible. To me this means a private nested struct. Which
I'll come to in a minute.
Daniel Frey wrote:
> That won't work as you made it a nested struct so it is still
> different for all instantiations. I think Dave meant to go for this
> one:
This was intentional for the reason I've just stated above. I don't see
this as any efficiency problem, as certainly on the two compilers I've tried
there was no instantiation of safe_bool at all, without optimisations. With
optimisations on all of the code inlined into the ideal x != 0. Ok on
_some_ compilers this may be an issue, but that goes for just about all
things in boost.
As for making safe_bool reusable, I can only see one possible reason. Where
someone would want to make if (x) a valid construct but not if (!p). Is
this enough reason to allow it? If so then it does not really belong in
boost/operators.hpp, more likely boost/utitlity.hpp.
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!
Sam
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
