Re: [boost] [Review] Shmem

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-02-10 13:20:49

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

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

Apart from this, little discussion, now that you are in the Shmem review 
thread, I would love if you could find time to review it. I think that 
your C++ knowledge is very interesting for a library that tries to put 
STL containers in shared memory and memory mapped files.

Regards (and waiting your review),

Ion