Re: [boost] [interprocess] default constructors

Subject: Re: [boost] [interprocess] default constructors
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2008-12-03 12:40:42

Mathias Gaunard wrote:
> The overhead I'm talking about is that allowing an empty state in the 
> object might have a cost.
> 
> A simple example is that if you have a function release(resource&), that 
> releases a valid resource, and you want to wrap that resource using 
> RAII, you have to write the destructor as
> 
> if(!is_empty)
>     release(res);
> 
> instead of simply
> 
> release(res);
> 
> So you need to maintain a boolean (size overhead) and perform a 
> branching (runtime overhead).
> 
> Usually, however, at least the size overhead can be eliminated since 
> there is a special resource value reserved for the null resource.

You are right. My point is that if you want to support a movable object:

{
   non_copyable_file_descriptor fd("filename");
   non_copyable_file_descriptor fd2(move(fd));
   //Both destroyed here
   //fd2 closes the file descriptor
   //fd is "empty"
}

you need to encode the "empty" state. Making the default constructor 
public or not is not the point. If we want to support non-destructible 
move-semantics we will always have this overhead in destructors.

There is a proposal to optimize these destructors:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2754.html

N2754: "Additional concepts: TriviallyDestructibleAfterMove and 
TriviallyReallocatable"

This will be very useful in containers, but I'm just thinking if 
compilers could be smart enough to avoid calling destructors for moved 
objects if the are TriviallyDestructibleAfterMove:

{
   //non_copyable_file_descriptor is
   //"TriviallyDestructibleAfterMove":
   non_copyable_file_descriptor fd("filename");
   non_copyable_file_descriptor fd2(move(fd));
   //Both destroyed here
   //fd2 closes the file descriptor
   //The compiler bypasses fd's destructor
}

Regards,

Ion