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