Boost logo

Boost :

From: Hamish Mackenzie (hamish_at_[hidden])
Date: 2005-10-18 09:53:43


On Tue, 2005-10-18 at 10:50 -0300, Fernando Cacciola wrote:
> The problems with optional<bool> are totally unrelated to the choice of
> operators * and ->.

True and I think if you could fix it you would find it much easier to
sell me on using * and ->. The issue I have with * and -> is that they
do not make it clear that the type in question is supposed to be an
optional (to someone reading the code). I still can't think of an
example where it is desirable to have X * and optional< Y > use the same
interface.

> It is the safe_bool() operator _alone_ which causes that.
> We can of course discuss whether such operator is worth it given the
> ambiguity it creates with optional<bool>. That was discussed at length at
> the time optional<> was reviewed (with me initially opposing safe_bool()),
> in the end, we agreed that it had more benefits than this simple
> counter-example.

I think this problem extends to other types eg. optional< int >. If I
have a function

template< typename RecordType >
void f( const RecordType & r )
{
        if( !r.some_integer_field() )
        {
                ...
        }
}

If the return value of some_integer_field is changed from int to
optional< int > will the meaning of the code change without a compiler
error?

In my experience with optional it is common place to change something
from required to being optional and back again.

> These alternatives fix the problem with optional<bool>.
> One example is to simply provide operator !, used like this:
>
> if ( !!opt )
> is_initialized();

I don't like this. I don't think it solves the problem just makes it
less common (as !bool_value still changes meaning when bool_value is
made optional).

Was there a problem requiring something like

if( opt != null_optional )
        is_initialized();

?

Hamish


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