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