Boost logo

Boost :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-09-17 14:57:37


On Monday 17 September 2001 11:35, you wrote:
[snip]
> With respect to the 'operator T*()', I haven't adopted it becuase it would
> allow the following:
>
> optional<int> opt1 = 1234 ;
> optional<int> opt2 = 1234 ;
>
> if ( opt1 == opt2) // this will compile OK if there is an 'operator
> T*()', but won't evaluate as expected.
>
> the above boolean expression is ill-formed w.r.t the optional
> specification, but there is no compile-time nor runtime indication of that.

You can "poison" comparisons between optional<T>'s very easily, however, like
this:

template<typename T1, typename T2>
void operator==(const optional<T1>&, const optional<T>&);

Since the operator == returns void, any attempt to use "opt1 == opt2" will
generate a compile-time error. In the pointless case that the user writes the
(harmless) statement expression "opt1==opt2;", the failure will occur at link
time.

> I decided to support only those idioms that would prevent the mistakes as
> above. AFAICT, these are (1) operator !(), (2) a friend 'T* get(opt)'
> function (thanks to Peter Dimov!).

Many of these concerns (how to use an object in a boolean context) were
discussed prior to the review of Function. I settled on the use of Peter
Dimov's pointer-to-member-of-useless-class technique for the boolean
conversion, and on poisoning operator== and operator!= for Function class
templates. The source file boost/function/function_base.hpp contains the code
for both.

The fact that this discussion has come up again hints that these solutions
should perhaps be documented somewhere. I would suggest the addition of a
"safebool" type to utility.hpp that assists in the object-to-bool conversion.
Similarly, operator poisoning would belong in operators.hpp: for instance, a
type "not_equality_comparable" could be derived from to poison operators ==
and != for the given class.

If there is interest I can submit these for review.

        Doug


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk