Braddock Gaskill wrote:
// alternative #3 - pass by value // Constructing shared_ptr's is VERY inefficient void f3(future f) { bool v = f.get(); // no problem, get() is const f.set(!v); // cannot do this, set() is not const }
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. In contrast, f.get() costs at best one atomic load and one memory barrier, and at worst blocks for an unspecified amount of time. f.set very likely costs one user-kernel transition (and a memory barrier), which is typically much more than a few atomic instructions. This of course doesn't address your const-correctness question, which disappears if you make f.set const. :-) In the next C++ we'll also have void f5( future && f ); as an option.