On Thu, 8 Jan 2009, Tom Brinkman wrote:
Ponderings on the Futures Library:
What is the status of Anthony Williams' submission of the futures library to the c++ standards committee?
Dunno.
Is it more prudent to wait to find out what the c++ standards committe is going to do first, before adding a possibly incompatible version of the futures library to boost?
Both approaches have benefits. - Early users may help the committee avoid bad decisions. - Waiting simplifies the life of end users.
One could ask, if Anthony's submission is approved by the c++ standards committe, what is the point of adding a "futures" library to boost as well?
If this exact submission were standardized, the Boost version would still be useful on older (standard) compilers.
Is a seperate library needed? What is the advantage of having a root level library called boost::futures? Why would it not be perferable to just extend boost::thread with the additional capabiltity to handle "futures"?
Not having read the code, it would seem the two should be separate unless they would benefit from heavy code reuse not available through the public APIs. More importantly, there should be benefits by having the boost::futures namespace closely reflect std::futures or whatever.
From the sidelines, Daniel