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