From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-10-17 12:27:53
Hi,
>
> I don't think that quite answers my question (but maybe it does) a simple
> example of what I would like to be able to do is:
>
> void main()
> {
> boost::interprocess::managed_shared_memory shm;
>
> if(shm.isInitialized()) // This functionality would be nice
> {
> shm.construct<int>()();
> }
> }
>
> Or
>
> void main()
> {
> boost::interprocess::managed_shared_memory shm;
>
> try
> {
> shm.construct<int>()();
> }
> catch(interprocess_initialized e) // This functionality is also ok
> {
> }
> }
managed_shared_memory has no default constructor (at least, in the
current cvs). During the Shmem there was a big discussion about this
issue and it was decided to drop the two phase construction. I know it's
sometimes ugly and uncomfortable, but it has advantages because you know
that the segment is always created/opened if you have a
managed_shared_memory object.
The hard part of this issue is that sometimes you want a
managed_shared_memory object as a member of a class, but you want to
delay the construction of that segment after some conditions are met:
class managed_shared_memory_holder
{
//...
managed_shared_memory segment;
};
Since you have to initialize the member in the constructor list, you
have to execute a function before constructing the member and throw an
exception if there is an error. Sometimes, this is no easy/pleasing.
Another alternative is to use dynamic memory:
class managed_shared_memory_holder
{
//...
auto_ptr<managed_shared_memory> segment;
};
and construct the segment in the constructor body
managed_shared_memory_holder::managed_shared_memory_holder()
{
segment.reset(new managed_shared_memory(create_only, ...));
}
If you have allergy to dynamic memory allocation like me, another
alternative is to use Boost.Optional. Anyway, this is a two phase
constructor. If move semantics were added I should/could define a
"default-constructed" managed_shared_memory that does nothing and that
it would be the state of an object after being moved:
managed_shared_memory_holder::managed_shared_memory_holder()
: managed_shared_memory() //default constructed
{
//If conditions are met
segment = move(managed_shared_memory(create_only, ...));
}
But with this move-semantics alternative we have a default-constructed
state (or just a "zombie" state after being moved) and that was
considered harmful in the Boost review, because reviewers explicitly
requested that guarantee.
I personally dislike not having the default-constructor (I would just
put an assert in debug mode) and I'm a big fan of move-semantics, but we
would need to re-review this issue (for example, if a move-semantics
emulation library is accepted) to get some consensus because it was the
most tricky topic in the review.
Regards,
Ion