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