Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-19 13:08:20


Rob Stewart wrote:
> From: "Peter Dimov" <pdimov_at_[hidden]>
>>
>> Also, I still think that the bool parameter is better than a
>> "locking" enum, as evidenced by the use case shown in the
>> specification:
>>
>> scoped_lock lock( m, want_to_lock? locking: non_locking );
>>
>> I find this an unnecessarily verbose and contrived way to express
>>
>> scoped_lock lock( m, want_to_lock );
>>
>> which is the original intent.
>
> I disagree. From the perspective of calling code, using a bool
> makes things more confusing:
>
> scoped_lock lock1(m, true);
> scoped_lock lock2(m, false);
>
> From this context, it isn't apparent what "true" and "false"
> mean. Yes, you can refer to the documentation, but what if
> you're new to scoped_lock and you forget what it means? Then
> you'll have to switch contexts, find the docuementation, read
> about the parameter, and then switch back to see what's really
> happening in the code.
>
> With the enum, however, the code is self-documenting:
>
> scoped_lock lock1(m, locking);
> scoped_lock lock2(m, non_locking);
>
> Thus, using the enum eliminates a source of errors and confusion
> whereas the conditional behavior you mention is still possible,
> if verbose.

You could have written that about any interface that takes a bool. Perhaps
if you take into account some specific properties of scoped_lock you'll be
able to argue more convincingly. For example:

- a 'locking' lock is actually spelled

    scoped_lock lock1( m );

- the conditional behavior was actually in Howard's specification as the use
case for the constructor, it wasn't merely mentioned by me;

- the non-locking case:

    scoped_lock lock2( m, false );
    scoped_lock lock2( m, non_locking );

usually crops up when lock2 is about to be try_locked or timed_locked
immediately thereafter. If we include

    scoped_lock try_mutex_lock( Mutex & m );

that enable Eric Niebler's

    if( scoped_lock lock2 = try_mutex_lock( m ) )

this will reduce the frequency of the "non-locking locks" considerably.


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