From: "Peter Dimov" <pdimov@mmltd.net>
Rob Stewart wrote:
From: "Peter Dimov" <pdimov@mmltd.net>
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: [snip] From this context, it isn't apparent what "true" and "false" mean. Yes, you can refer to the documentation, but what if [snip] 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
Exactly.
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 );
Then why wasn't the example written like this? scoped_lock lock(want_to_lock ? scoped_lock(m) : scoped_lock(m, non_locking)); That was a rhetorical question (IIRC, and I'm not following this discussion closely, scoped_locks are not copyable, so you can't write this version).
- the conditional behavior was actually in Howard's specification as the use case for the constructor, it wasn't merely mentioned by me;
OK, but you used it as the basis for justifying using bool rather than the enum. I'll grant you that I didn't have the whole picture to which you were apparently alluding; I just took your statements at face value.
- 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.
Doesn't that argue for the case of making the "key" that indicates that the lock should be "non-locking" more explicit than a bool? IOW, if one is rarely going to write "scoped_lock(m, false)," then the meaning of "false" is even more obscure and "non_locking" is even more appropriate. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;