Re: [boost] [interprocess] Segment existance check

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