I'm looking at all these "operator unspecified_bool_type"s in Boost. They vary: It's hard to get all of these right, and various Boost libraries have made changes in the past that got it wrong: type-safety compiler workarounds zero runtime overhead (a.k.a. more compiler workarounds) In fact I haven't previously seen an implementation that obviously achieves safety in the general case. Even pointer-to-members have an operator== and operator!=, which will cause trouble if the boolean-convertible type doesn't have its own operator== and operator!= (although it often does). But it is possible! I thought it required macros at first, but it actually works better(in some ways) with the Curiously Recurring Template Pattern. If you, the user, make a class C (such as shared_ptr) that you want to have an operator safe-bool, derive from a boost::convertible_to_bool<C> (and define a member of C "bool operator_bool() const"). Boost shall have, in order to generate errors for invalid operations, the following: template<typename T>operator==(boost::convertible_to_bool<T>const&, boost::unspecified_bool_type); template<typename T>operator==(boost::unspecified_bool_type, boost::convertible_to_bool<T>const&); and similar for operator!=, and (when unspecified_bool_type is a function pointer) for <, >, <=, >=. (The return type is something clever like boost::TYPES_MAY_NOT_BE_COMPARED_IMPLICITLY_VIA_BOOLEAN_CONVERSIONS to improve error messages.) When the compiler has support for the C++0x "explicit operator bool", none of these hacks are needed, and the library can adjust to that too. There are several more details I've been looking at too... ADL, base-chaining like Boost.Operators, writing tests/docs for weird inheritance situations... :-) Perhaps this should be provided as a Boost library in its own right, and Boost should use it everywhere that Boost currently uses idiosyncratic operator safe-bools. Are there any pitfalls I'm missing? (are there important compilers that can't deal with the overhead or correctness of using a base class for this purpose?) Does this sound like a good idea? I can post my code soon if there's interest. -Isaac
Isaac Dupree wrote:
I'm looking at all these "operator unspecified_bool_type"s in Boost. They vary:
It's hard to get all of these right, and various Boost libraries have made changes in the past that got it wrong: type-safety compiler workarounds zero runtime overhead (a.k.a. more compiler workarounds)
At some time, there was a safe-bool thingy in Boost.Operators, but it was removed. I honestly do not know why.
Mathias Gaunard wrote:
Isaac Dupree wrote:
I'm looking at all these "operator unspecified_bool_type"s in Boost. They vary:
It's hard to get all of these right, and various Boost libraries have made changes in the past that got it wrong: type-safety compiler workarounds zero runtime overhead (a.k.a. more compiler workarounds)
At some time, there was a safe-bool thingy in Boost.Operators, but it was removed. I honestly do not know why.
Well, I found http://www.pdc.kth.se/training/Talks/C++/boost/libs/utility/operators.htm#sa... and http://lists.boost.org/Archives/boost/2003/03/45401.php not contained here: http://www.boost.org/doc/libs/1_31_0/libs/utility/operators.htm the changelog of the first link mentions a change in '05 that isn't in mainline. The thread goes some way pointing out pitfalls. I had some difficulty reading the thread, but it seems to start here: http://lists.boost.org/Archives/boost/2003/02/44923.php Anyway then it just ends. Maybe it wasn't ever finished and included into boost?
On Sun, 2008-08-10 at 17:36 +0200, Mathias Gaunard wrote:
Isaac Dupree wrote:
I'm looking at all these "operator unspecified_bool_type"s in Boost. They vary:
It's hard to get all of these right, and various Boost libraries have made changes in the past that got it wrong: type-safety compiler workarounds zero runtime overhead (a.k.a. more compiler workarounds)
At some time, there was a safe-bool thingy in Boost.Operators, but it was removed. I honestly do not know why.
The code that landed in CVS for a time is not based on the safe-bool idiom, but on an alternative approach: It simply adds a private declaration of an "operator signed char() const". When the used implements "operator bool() const", conversion to bool works while conversion to other types are ambiguous (e.g. int) or private (e.g. signed char). The problem was that it broke is_convertible: is_convertible<A,int>::value resulted in a compile-time error instead of returning false - which is the reason why the code was removed from CVS before it was ever released. Regards, Daniel
Daniel Frey wrote:
On Sun, 2008-08-10 at 17:36 +0200, Mathias Gaunard wrote:
Isaac Dupree wrote:
I'm looking at all these "operator unspecified_bool_type"s in Boost. They vary:
It's hard to get all of these right, and various Boost libraries have made changes in the past that got it wrong: type-safety compiler workarounds zero runtime overhead (a.k.a. more compiler workarounds) At some time, there was a safe-bool thingy in Boost.Operators, but it was removed. I honestly do not know why.
The code that landed in CVS for a time is not based on the safe-bool idiom, but on an alternative approach: It simply adds a private declaration of an "operator signed char() const". When the used implements "operator bool() const", conversion to bool works while conversion to other types are ambiguous (e.g. int) or private (e.g. signed char).
The problem was that it broke is_convertible: is_convertible<A,int>::value resulted in a compile-time error instead of returning false - which is the reason why the code was removed from CVS before it was ever released.
argh! And there was a good reason for that private operator signed char. Which is equivalent to providing several operator some-int()s for every builtin integral type. If we did that, at least it would be just an access error rather than an ambiguity error*. But I'm not sure if that helps us. Conceivably, safe_bool could friend is_convertible and is_convertible could special-case for it. But how could it detect when a derived class actually does implement an operator? Can is_convertible<T,int> where T is directly or indirectly derived from safe_bool<>, take the address &T::operator int, and then see whether the class type of the resulting value is of type safe_bool<> (in which case it's not convertible), or else it'll be of some derived type, in which case it is convertible. I'm not sure if anything like that is possible in the standard, let alone the implementations we support. But maybe it is? (for a large penalty in hack-ness.) * (Which might make the error messages better? or worse?) -Isaac
participants (3)
-
Daniel Frey -
Isaac Dupree -
Mathias Gaunard