Boost logo

Boost :

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-08-25 14:52:01

Peter Dimov wrote:
> Yuval Ronen:
>> Peter Dimov wrote:
>>> I meant "helps people avoid accidental mistakes at the time they're
>>> writing
>>> the code". The function encourages correct use by asking for a lock,
>>> implying that the mutex needs to be locked first.
>> Hinting the user to lock a mutex by accepting a lock is getting too
>> psychological for my taste. If it was enforced by the compiler, then
>> maybe, but since the compiler can't...
> The hint isn't particularly subtle. You have to pass a lock, and this _is_
> enforced by the compiler. The rest of the enforcement (that the lock 'owns'
> the correct mutex) is necessarily postponed to run time; we simply can't do
> better than that.
> I'm really not sure how you propose to achieve the same level of encouraging
> and enforcing correct use with a wait function that doesn't take a lock
> argument,

I'm saying that there's no need to achieve the same level of enforcing.
Checking in runtime is enough, IMO. Just as we don't enforce locking
before accessing a shared resource (because we can't), there's no need
to go over hoops (see my next paragraph) to enforce more than at runtime.

> and I'm also unsure what specific problems with requiring a lock
> argument are you trying to solve.

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at