Boost logo

Boost :

Subject: Re: [boost] [thread] Use of synchronized_value<> member in a constructor
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-06-16 17:54:06


Le 13/06/13 12:43, Klaim - Joël Lamotte a écrit :
> On Thu, Jun 13, 2013 at 8:13 AM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>>> Anyway, I might be wrong but it seems to me that any attempt to combine
>>> use
>>> of several synched members in the constructor
>>> will imply locking OR adding several layers of abstractions, which if the
>>> members' types have value-semantic, can be easy,
>>> but if it's not the case, it becomes quickly very noisy.
>>>
>> I agree. We surely need something that make this easier and less noisy. I
>> would prefer if we continue to see other alternatives to go directly to
>> providing a bypass function.
>>
>>
> Yes. I am thinking maybe part of the solution would be to have a second
> optional argument in the synchronized_value<> constructor which would be
> lambda
> which would be called in the constructor body of the synchronized_value<>:
>
> explicit Sequence( SequenceInfo info )
> : m_infoproc( info , []( InfoProcessor& infoproc ){
> infoproc.do_something(); } ) // no locking - lamda called in
> synchronized_value<>
> constructor
This could be added, but I don't think it is elegant.
>
> It don't solve the case where you want to use several members in the
> Sequence construuctor though.
> Is there any way in C++ to detect if we are in an object's construction? I
> think not.
> It would the opposite of the proposal for detecting when an exception have
> been thrown and stack-unwinding is occuring.
>
> I can't think of a better solution right now.
>
>
I was wondering if a not yet existing synchronized_value<T&> could help
in your context.
You would need to declare a value and a reference.

explicit Sequence( SequenceInfo info )
: m_value( info ), m_ref(M_value)
{
   m_value.do_something(); // no need to lock.
}

Vicente


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