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: 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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;