Quantcast

operator safe-bool?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

operator safe-bool?

Isaac Dupree
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: operator safe-bool?

Mathias Gaunard-2
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: operator safe-bool?

Isaac Dupree
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#safe_bool_note
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?
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: operator safe-bool?

Daniel Frey-3
In reply to this post by Mathias Gaunard-2
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: operator safe-bool?

Isaac Dupree
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Loading...