Boost logo

Boost :

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-11-01 05:01:15


Anthony Williams wrote:
> Roland Schwarz <roland.schwarz_at_[hidden]> writes:
>> Not sure what this exactly means, can you exemplify?

<examples of simple interface snipped>

Ok, this was nearly obvious to me, I was asking about the "platform
and compiler specific ways".

I cannot however understand why one would insist on:

> class X
> {
> std::mutex class_data_member;
>
> X()
> {}
>
> };

while still accepting the need to:

class X
{
     int data_member;

     X() : data_member(42)
     {}
}

What is wrong or "unsimple" about:

clsss X
{
     std::mutex class_data_member;

     X() : class_data_member(0)
     {}
}

>> scoped_lock lk(&foo); should be enough. Implementing this efficiently
>> however is another story.
>
> No, that's not what I meant. The proposal(s) before the Standards committee
> are for an explicit mutex type. By "simplest interface" I meant not requiring
> any explicit initialization under any circumstances.

But scoped_lock lk(&my_foo); does "not require any explicit
initialization under any circumstances". (With respect to mutex).
This even beats the class_data_member case. You even can use
it from inside global ctors.

Btw.: This interface would also be backwards compatible to the
"explicit mutex lovers": Simply define an pseudo mutex object of
name mutex. Since it has an address it also will be usable as
an argument to lock.

We were always looking for sync primitives that really are C++ way.
The most important new thing (with respect to C) is: scoped_lock !
This really is compelling. So why not take the full step and get
rid of the "helper class" mutex too? The only really indispensable
property of a mutex is its ID.

Roland


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk