Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net