Tom Brinkman-2 wrote:
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?
It would certainly be very unfortunate if the two implementations proved incompatible. OTOH, standardizing a library without having an existing well tested implementation is quite risky (look at std::string). In my understanding the C++ committee has very limited resources. I have no doubts that the committee members are very skilled and experienced programmers but there probably hasn't more than a few people involved in designing std.futures. A boost review and library can give them valuable feedback, that's the whole point of boost. Even though the experience from boost.futures might arrive too late to change the std.futures proposal it might allow them to remove std.futures and add it later on. I am personally very worried that Anthony's implementation has been too rushed and has had too much focus on being applicable to thread pools. See my review for more details. Tom Brinkman-2 wrote:
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?
Another important point is that a boost library can be available years sooner than widespread C++ standard implementations will. Best Regards, Johan Torp www.johantorp.com -- View this message in context: http://www.nabble.com/Pondering-Futures-tp21359362p21387404.html Sent from the Boost - Dev mailing list archive at Nabble.com.