|
Boost : |
From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-08-25 16:39:15
Howard Hinnant wrote:
> On Aug 25, 2007, at 2:52 PM, Yuval Ronen wrote:
>
>> I find the lock argument cumbersome. In a way it's redundant to
>> passing
>> the mutex, and for no good reason - just for hinting, subtle or no
>> subtle. Where else in C++ a user is hinted in such a way? It's without
>> precedent, and plain weird in my eyes. And if we add to this the fact
>> that it's only a partial compile-time check, then it makes things even
>> weirder. The user, for example, can confuse and think that he is fully
>> covered by the compile-time check, and continue with his guards down,
>> passing it a non-owning unique_lock. If we can't do a complete job,
>> it's
>> better to not do it at all, at least this way our users are forced
>> to be
>> aware of what's happening.
>
> We have to have a wait which takes at the very least a mutex, if not a
> lock. This is to support the legal "dynamic" binding mutex binding.
> We could possibly achieve the same functionality through your
> set_mutex suggestion, but that interface seems error prone to me, as
> it then takes two calls to wait instead of one:
More "error prone" is in the eyes of the beholder, I guess...
> One possibility would be to have both wait(lock) and set_mutex(mutex)/
> wait(). But this doesn't allow anything that wait(lock) alone allows.
I'm not advocating those overloads, not at all.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk