[cpp-threads] RE: "Agenda" for august 23-25 concurrency meeting

[Howard Hinnant]

I fear I've muddled my message...

In C++03, functional programming is not without fear, worry, and/or  
guilt.  E.g. I need to compute a vector<int> and return it to the  
client.  How should I do that?

Today's advice is to pass an empty vector to your function by  
reference, out of fear that if you were to return it by value, RVO  
will not kick in:

     void compute(vector<int>& v, input data);  // guaranteed efficient

vs:

     vector<int> compute(input data);  // is this ridiculously  
expensive?



           *** Move semantics enables guilt-free functional  
programming. ***


I.e. you can return expensive items (such as vector<int>) by value  
from a function.  Either RVO will kick in, or failing that, move  
semantics will kick in.  Either way, the expense of the return type  
is no longer a barrier to clean functional-style interfaces.  As  
people learn this (and get such compilers in their hands), they will  
prefer the cleaner interface for everyday, ordinary functions:

     vector<int> compute(input data);

The question I put before us, and strongly recommend that we answer  
positively is:

     For asynchronous function calls, do we offer some mechanism for O 
(1) performance
     of the return type as we do for synchronous function calls?

     thread<vector<int> > t = launch_thread(bind(compute, input data));
     vector<int> v = t();  // is this ridiculously expensive?

We can have both (copyable) futures and efficient mechanisms for  
returning heavy values from threads.  We do not have to lock our  
customers into one design or the other in this engineering tradeoff.

-Howard