Re: [boost] [interprocess] default constructors

Subject: Re: [boost] [interprocess] default constructors
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2008-11-30 15:34:31

Mathias Gaunard wrote:
> Why not simply delay the construction of the managed shared memory 
> segment until you have the required arguments to initialize it?
> 
> The original poster said he could have used pointers and dynamic memory 
> allocation to achieve that, but that's a fairly inefficient way of doing 
> it.
> It is perfectly possible to simply use a POD with compatible size and 
> alignment as a global variable, then construct it as the desired object 
> once possible.

Yes but the destructor is not called.

> This is basically what boost::optional does, except it also uses a 
> boolean to know whether destruction must be performed or not.

Correct. But not everyone likes to use optional and pay the overhead of 
an additional bool that must be also stored inside managed_shared_memory 
(either explicitly or implicitly, via an internal state) to support move 
semantics. Some might not like to have a default-constructor that 
represents an empty class, but it's a design decision.For example, 
unique_lock:

http://www.boost.org/doc/libs/1_37_0/doc/html/thread/synchronization.html#thread.synchronization.locks.unique_lock

supports default construction and eases moving values in branches 
without using optional:

unique_lock<mutex> u;

//If thread-safe use a lock, avoid it otherwise.
if(thread_safe){
    u = move(unique_lock(internal_lock_));
}

//thread-save code depending on the branch...

Regards,

Ion