Re: [Boost-users] shared_ptr, pimpl, reference semantics, and const correctness

From: Braddock Gaskill (braddock_at_[hidden])
Date: 2007-08-01 17:23:50

Hi Peter,

On Wed, 01 Aug 2007 20:07:27 +0300, Peter Dimov wrote:
> Braddock Gaskill wrote:
>> // alternative #3 - pass by value
>> // Constructing shared_ptr's is VERY inefficient
> 
> The construction of the shared_ptr (if not optimized out when the source is 
> an rvalue) consists of one atomic increment. Its destruction at the end of f 
> costs one atomic decrement and one memory barrier.

I guess "VERY inefficient" is a relative term.  I just spent a weak
optimizing a DOM library where I attempted to use shared_ptr's in all
element references to parse documents with millions of elements.  Probably
an inappropriate use from the start. As you point out, a future is not a
flyweight class, so it may not be as critical.

> This of course doesn't address your const-correctness question, which 
> disappears if you make f.set const. :-)

Yes, I am considering that, but it seems semantically crooked.

What would you recommend?  I'm trying to stay on the same page as your
N2185 futures proposal.  Your proposal does not define set_value() as
const, so users will presumably face the same issues.  

I can force users to pass by future value, but that doesn't feel like good
practice and completely negates any const awareness anyway.

Does "&&" remove this concern for N2185? (I'm not really familiar with the
upcoming language features).

Thanks,
Braddock Gaskill