Re: [boost] Re: Lock unification [move]

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-07-19 12:15:22

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.

Another way to eliminate the source of errors is to provide
helper functions as the only way to create the locks:

   scoped_lock lock1(make_locking_scoped_lock(m));
   scoped_lock lock1(make_non_locking_scoped_lock(m));

That makes your example, and all scoped_lock code, uglier,
though:

   scoped_lock lock(want_to_lock
      ? make_locking_scoped_lock(m)
      : make_non_locking_scoped_lock(m));

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;