Re: [boost] [Review] Shmem

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-02-11 01:27:45

> In my opinion 'yes'. Look at the frequency of comp.lang.c++ posts related to 
> problems of the stream being in an unanticipated state when attempting to 
> re-open it. I don't think streams are one of the most exemplary of standard 
> library classes.

But that's because the flags are not reset after a close. Not because of 
the two phase initialization. If close() guarantees default constructor 
state, there are no such problems.

>> have to use the constructor to open the shared memory I can't make
>> boost::shmem::shared_memory a member of a class if the class has a
>> different lifetime than the shared memory. Even if I have the same
> 
> Then use the accepted idiom of dynamically creating a new instance.

Why? If I provide both RAII and default+open you can choose what to use. 
I'm not saying that RAII can't be used. I'm saying that with Shmem you 
can use the method you want. Dynamically allocation requires also 
external management against exceptions (smart pointers or whatever). The 
same management you need with two phase initialization (a final 
rollback/release) to get a rollback if an exception is thrown.

>> lifetime, maybe I have to do some validations/operations to obtain the
>> parameters for the segment that can't be made (or would be really ugly
>> and complicate to do) in the member initialization list. Using RAII
> 
> Can you show specific examples?
> 
>> only approach I have to dynamically allocate it. And to open another
>> segment
>> I can't reuse the object, I have to destroy it and allocate a new one.
> 
> Can you show how that cost would be prohibitive versus open/close?

Cleary in Shmem primitives is not prohibitive. You don't map one million 
segments. But as a general Good Thing rule as it's presented here, it's 
clear that dynamic allocation is a serious overhead (even worse if you 
use shared_ptr).

> I don't view RAII as fad that someone thought was cool. RAII has been proven 
> to avoid many problems that are pandemic with two-phase-construction. I've 
> also seen that RAII reduces the amount of error checking code required to 
> handle attempts to call functions while the object is not in a valid state. 
> It also simplifies the interface and required documentation. As is, you 
> would need to clearly document what combinations of conditions are required 
> in order to be able to use every member function.

I won't discuss that RAII is very convenient and useful. I use RAII very 
often and I try to avoid try/catch using destructors to free resources. 
But this is like problem like providing mutex locks ONLY through 
lockers. In some sw small enterprises I know (mine included), exceptions 
are not recommended (allowed) in the code. That can be because of 
misinformation but that's the reality. Even some programmers (I'm one of 
them), don't like exception model at all. And I agree with you that I 
need more documentation with two phase construction. Do you think that 
providing both methods will lead programmers to the "bad way"?

Regards,

Ion