needs coroutine2 a review?
coroutine2 is a C++14-only library, providing cleaner code (maintainability) + it fixes some issues (moveable-only parameters). boost.coroutine will be deprecated. The conclusion of the last discussion ( http://boost.2283326.n4.nabble.com/transforming-ex-boost-lib-into-C-11-only-...) was to establish coroutine2 as a separate lib beside of boost.coroutine - similar to boost.signals(2). I'm wondering if coroutine2 needs a review, even if the interface remains the same compared to boost.coroutine. Oliver
Le 02/06/15 11:00, Oliver Kowalke a écrit :
coroutine2 is a C++14-only library, providing cleaner code (maintainability) + it fixes some issues (moveable-only parameters). boost.coroutine will be deprecated. Up to when boost.coroutine will be deprecated? By what users of boost.coroutine in c++98 would replace the deprecated library? Is there any library in Boost that depends on Boost.Coroutine? I've the impression that you will need to maintain it still for some years.
The conclusion of the last discussion ( http://boost.2283326.n4.nabble.com/transforming-ex-boost-lib-into-C-11-only-...) This thread doesn't contains the coroutine word on the title :( was to establish coroutine2 as a separate lib beside of boost.coroutine - similar to boost.signals(2).
I'm wondering if coroutine2 needs a review, even if the interface remains the same compared to boost.coroutine.
In your case, you are adding more but restricted to C++14 compilers. I don't think that review is needed in this is the case. I believe that it is up to you to decide if you needs a review. Spirit uses to request a review for each new version, but the interface are not preserved. Best, Vicente
2015-06-21 11:05 GMT+02:00 Vicente J. Botet Escriba < vicente.botet@wanadoo.fr>: Up to when boost.coroutine will be deprecated? when boost.coroutine2 is added to the release (but boost.coroutine will still be avaiable)
By what users of boost.coroutine in c++98 would replace the deprecated library?
boost.coroutine will still be part of the release see discussion ([boost] transforming ex. boost lib into C++11-only lib?) http://lists.boost.org/Archives/boost/2015/01/219507.php
Is there any library in Boost that depends on Boost.Coroutine?
boost.asio
I've the impression that you will need to maintain it still for some years.
for bug fixing, yes
In your case, you are adding more but restricted to C++14 compilers. I don't think that review is needed in this is the case.
OK
Le 21/06/15 11:20, Oliver Kowalke a écrit :
2015-06-21 11:05 GMT+02:00 Vicente J. Botet Escriba < vicente.botet@wanadoo.fr>:
Up to when boost.coroutine will be deprecated?
when boost.coroutine2 is added to the release (but boost.coroutine will still be avaiable) When we deprecate something, we usually deprecate it until I given date. SO my question is up to when it will be available in the deprecated mode? If there is not date iy shouldn't be deprecated.
By what users of boost.coroutine in c++98 would replace the deprecated library?
boost.coroutine will still be part of the release
see discussion ([boost] transforming ex. boost lib into C++11-only lib?) http://lists.boost.org/Archives/boost/2015/01/219507.php So it will not be deprecated.
Is there any library in Boost that depends on Boost.Coroutine?
boost.asio So it can not be deprecated.
I've the impression that you will need to maintain it still for some years.
for bug fixing, yes Ok.
Vicente
On 21.06.2015 12:05, Vicente J. Botet Escriba wrote:
Le 02/06/15 11:00, Oliver Kowalke a écrit :
coroutine2 is a C++14-only library, providing cleaner code (maintainability) + it fixes some issues (moveable-only parameters). boost.coroutine will be deprecated. Up to when boost.coroutine will be deprecated? By what users of boost.coroutine in c++98 would replace the deprecated library? Is there any library in Boost that depends on Boost.Coroutine?
Boost.ASIO depends on Boost.Coroutine, although I didn't dig deep enough to know strong the dependency is.
I've the impression that you will need to maintain it still for some years.
+1. As long as Boost.ASIO remains a C++03 library it cannot be ported to Boost.Coroutine2. Either Boost.ASIO has to be ported to a different coroutine implementation or Boost.Coroutine has to remain in Boost and be maintained.
I'm wondering if coroutine2 needs a review, even if the interface remains the same compared to boost.coroutine.
In your case, you are adding more but restricted to C++14 compilers. I don't think that review is needed in this is the case.
I believe that it is up to you to decide if you needs a review. Spirit uses to request a review for each new version, but the interface are not preserved.
I don't think I've seen a review request for X3. Anyway, Oliver, if your library design is the same and interface is unchanged then the only reason you might want people to review your library is to have someone inspect the implementation and perhaps docs. It's a very valid reason and you are welcome to request a review, but bear in mind that the main focus point of Boost reviews is design and interface, so you might not receive as much feedback. A mini-review might be better. OTOH, if Boost.Coroutine2 is a new design then I think review is in order.
On 06/21/2015 11:31 AM, Andrey Semashev wrote:
Boost.ASIO depends on Boost.Coroutine, although I didn't dig deep enough to know strong the dependency is.
AFAIK, the integration with Boost.Asio is limited to a single header
(
2015-06-21 13:34 GMT+02:00 Bjorn Reese
(
) which you only include if you want to use coroutines. This header is one of those "bridge headers" which does not really belong to either library.
I would suggest to use execution_context directly instead of coroutine<>
participants (4)
-
Andrey Semashev -
Bjorn Reese -
Oliver Kowalke -
Vicente J. Botet Escriba