[future] @Tom -> review result?
One last sentence, we should not forget that the interface of the future library has already gone through the standard committe.
It should work the other way around. Are we going to start picking through libraries that have already been standardized in Cx0 and begin adding them to boost? Not a good idea in my view. The interface is already available. Use it. But why go to the trouble of adding it as a top-level boost library to a library. What is so special about the futures library? Why does Anthony not just slip "futures" it into boost::threads. He maintains that library. Its a non-issue. He doesn't need our approval to do that. Considering the way this review has floundered at this point, that is the best outcome that I can see. If we put it up for review again as top-level boost library, it will need to be fully documented, with samples and test cases. The library has been on the review boards for over a year. Plenty of time for these to have been added. //Tom
----- Original Message ----- From: "Tom Brinkman" <reportbase@gmail.com> To: <boost@lists.boost.org> Sent: Friday, February 13, 2009 5:35 PM Subject: [boost] [future] @Tom -> review result?
One last sentence, we should not forget that the interface of the future library has already gone through the standard committe.
It should work the other way around.
Are we going to start picking through libraries that have already been standardized in Cx0 and begin adding them to boost?
If implementations were available on all the platforms I didn't care about that. There are some libraries as Chrono, UniquePtr and Futures that will help to make uniform other Boost libraries. There is also the emulation of Move semantics and other that I don't kwow that will make eassier the transition to C++0x.
Not a good idea in my view. The interface is already available. Use it. But why go to the trouble of adding it as a top-level boost library to a library.
Because other libraries need it, and Futures are not an implementation detail. The users needs to use them.
What is so special about the futures library?
Other than an interface already exists in C++0x. This is already the case for the Chrono and UniquePtr library, which I hope will be subject to a review, not for the interface, but yes for the documentation, implementation and tests.
Why does Anthony not just slip "futures" it into boost::threads. He maintains that library. Its a non-issue. He doesn't need our approval to do that.
Well I don't know if this is sohaitable.
Considering the way this review has floundered at this point, that is the best outcome that I can see.
If we put it up for review again as top-level boost library, it will need to be fully documented, with samples and test cases. The library has been on the review boards for over a year. Plenty of time for these to have been added.
I agree with you that the documentation needs to be improved. I think reviews are needed for library acceptation but also to improve them. Tom as the Review Manager, please, could you clarify all these points with the authors as soon as you can. Best, Vicente
Hello Tom, "Tom Brinkman" <reportbase@gmail.com> schrieb im Newsbeitrag news:30f04db60902130835qa9bdd5fs1f450b77f7b26e1d@mail.gmail.com...
Are we going to start picking through libraries that have already been standardized in Cx0 and begin adding them to boost?
Not a good idea in my view. The interface is already available. Use it.Ž
As long as there aren't available implementations for the platforms boost support, I think it is a good idea to do so. Additionally, we would be able to extend and evolve such an interface and implementation.
What is so special about the futures library?
It could be the backbone for higher level libraries. They may bring multithreading programming to the mass.
Why does Anthony not just slip "futures" it into boost::threads. He maintains that library. Its a non-issue. He doesn't need our approval to do that.
IMHO, future concepts deserve a separate library.
If we put it up for review again as top-level boost library, it will need to be fully documented, with samples and test cases.
Yes.
The library has been on the review boards for over a year. Plenty of time for these to have been added.
To make a library proposal to the community is one think. But to wait for review and stay tuned is another one. So the question to ask is whether one of the authors or another qualified person is willing to bring forward a boostifiable implementation according to the approved interface. Best, Johannes
Tom Brinkman <reportbase@gmail.com> writes:
One last sentence, we should not forget that the interface of the future library has already gone through the standard committe.
Why does Anthony not just slip "futures" it into boost::threads. He maintains that library. Its a non-issue. He doesn't need our approval to do that.
I did not do this precisely because Braddock submitted his library for review before mine was ready. If my implementation of futures had been the only one, I would have just added it as an extension of the thread library. Because Braddock had submitted an alternate implementation with a distinct interface it seemed presumptious of me to add it to Boost.Thread. I also hoped it would be reviewed before WG21 got to vote on the proposals, so the review could provide feedback to the committee.
Considering the way this review has floundered at this point, that is the best outcome that I can see.
I am happy to do this if that's what people want. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Friday, February 13, 2009 10:03 PM Subject: Re: [boost] [future] @Tom -> review result?
Tom Brinkman <reportbase@gmail.com> writes:
Considering the way this review has floundered at this point, that is the best outcome that I can see.
I am happy to do this if that's what people want.
Anthony
And Braddock ?
Tom Brinkman wrote:
But why go to the trouble of adding it as a top-level boost library to a library. What is so special about the futures library?
Why does Anthony not just slip "futures" it into boost::threads. He maintains that library. Its a non-issue. He doesn't need our approval to do that.
Considering the way this review has floundered at this point, that is the best outcome that I can see.
If we put it up for review again as top-level boost library, it will need to be fully documented, with samples and test cases. The library has been on the review boards for over a year. Plenty of time for these to have been added.
IMHO, such approach simply ruins the review process entirely. Library maintainers are free to improve their libraries without a review, but this case is clearly not a simple improvement, and it should be properly reviewed. If it doesn't pass the review, it should be rejected at this point. Futures are no different from any other library in this regard. If we establish practice of such privileged library submission, we have to admit that reviews procedure doesn't work and have to be revised. As for conformance to the C++0x interface, I don't consider this relevant in any way to the library submission process. This is one of the submitted libraries feature, which may or may not be a prerequisite for the evaluated library. Fulfilling this prerequisite doesn't automatically mean acceptance. Personally, I don't consider strict conformance as a must. We use dosens of libraries that don't have analogues in C++ standard and it doesn't make them any less useful. All above is strictly my personal opinion.
participants (6)
-
Andrey Semashev -
Anthony Williams -
Johannes Brunen -
Steven Watanabe -
Tom Brinkman -
vicente.botet