Re: [boost] [Review] Shmem

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-11 15:38:01

Ion Gaztañaga <igaztanaga_at_[hidden]> writes:

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

Then consider making the class with 2-phase initialization a different
type.

> I would 
> like to point out that as it's using the same model as Shmem, fstream 
> from the standard library is also broken. 

I never said that was broken.  I did say that the guarantees it offers
are so weak that reasoning about correctness becomes more difficult
than it would otherwise be.

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

Even though I never used the term half-baked, I will accept it.  In
fact, it's perfectly apt.  The object can't be used in all the normal
ways one uses a file.

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

Use boost::optional or scoped_ptr.

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

Sorry, I can't visualize what you're describing.

> Using RAII only approach I have to
> dynamically allocate it. 

There's always optional.

> And to open another segment I can't reuse
> the object, I have to destroy it and allocate a new one.

There's no reason you can't make it reopenable.

> Default "empty" state (which is not the same as "zombie", because the 
> class is fully constructed) allows also move semantics between
> classes. 

Having such an empty "destructible-only" state is a an unfortunate but
necessary side effect of move optimization, but it is not necessary to
make such objects available for immediate use as the ctor does.  After
moving away, the object is impossible for the user to touch (unless
move() has been used explicitly).

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

I don't know what you mean.

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

That logic is flawed.  There are lots of examples of bad design in the
standard library.  fstream is hardly the worst.

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

What I've been discussing here is one of the few deep aspects of my
C++ knowledge, and one of the few aspects that you're not likely to
get from others -- i.e. it is to some extent my unique contribution --
yet it seems like you're not really very interested in it.  That
doesn't leave me feeling very encouraged about further participation.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com