Re: [boost] [Review] Shmem

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2006-02-10 14:22:16

Ion Gaztañaga wrote:
>>> Ok. I think I can provide both approaches so that who doesn't want
>>> (or can't because of a restricted embedded enviroment) use
>>> exceptions can have its alternative.
>>
>>   < C R I N G E >
>>
>> If you really *must* provide 2-phase construction, then please make
>> it a special mode that can be enabled with an #ifdef.
>
> I see you have strong opinions like me. So, no ifdefs, please. I would
> like to point out that as it's using the same model as Shmem, fstream
> from the standard library is also broken. If I can do:
>
>    std::fstream file;
>    //... some code
>    file.open();
>    //The destructor closes the file
>
> Is this a extremely harmful code? If that's ok, what's the difference
> with:
>
>    boost::shmem::shared_memory segment;
>    //... some code
>    segment.open();
>    //The destructor closes the segment
>
> Is "std::fstream file;" a "half-baked", "zombie" object? If you only

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.

> 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.

> 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?

> Default "empty" state (which is not the same as "zombie", because the
> class is fully constructed) allows also move semantics between
> classes.
> If you can only only the constructor and the destructor to open/close
> the segment you can't move the object to the target, since the source
> object can't be in a constructed state without owning the shared
> memory.

I'm not familiar enough with the requirements of move semantics to be able 
to judge that.

> I really don't like the "you should ONLY do this" approach. That's
> because what now is cool, some years later is demonized. I want
> choice.
> I don't like the approach of boost::thread, so I have to create a new
> boost::thread object every time I want to launch a thread. And I'm not
> the only one. With boost::thread, I can't have member boost::thread
> objects in classes (or I have to use optional<> like hacks)
>
> No silver bullet. No Good Thing (tm). If RAII is considered a good
> approach, I agree with you that I should provide it. But if fstream is
> good enough for the standard library, I think it can be a good model
> for Shmem without ifdefs.

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.

Jeff Flinn