On 12/1/21 00:40, Oliver Kowalke via Boost wrote:
Andrey Semashev via Boost
schrieb am Di., 30. Nov. 2021, 21:00: On 11/30/21 22:28, Peter Dimov via Boost wrote:
Andrzej Krzemienski wrote:
Please correct me if I am wrong, but my understanding is that Boost.ASIO works under C++03, and so does Boost.Coroutine. Whereas Boost.Coroutine2 requires C++11. If Boost.ASIO were to switch from BoostCoroutine to Boost.Coroutine2, it would break its C++03 guarantee. (Some teams in my work still have to use C++03.)
It's a bit more complex than that. Boost.Coroutine depends on Boost.Context, which is C++11. However, in order to not break C++03, Coroutine doesn't use the public API of Context, but the private "fcontext" parts that are kept C++03 compatible only because of that. This incidentally means that if you compile Context with the `ucontext` backend instead of the `fcontext` one, Coroutine breaks.
So it's basically a mess and needs to be cleaned up. Since asio::spawn is a separate part of Asio, moving just it to C++11 wouldn't be as disruptive a change as requiring C++11 for all of Asio.
I wonder how much of Boost.Context actually requires C++11. From my admittedly naive perspective, it should mostly be a bunch of assembler bits and/or interface glue for system APIs like ucontext, none of which inherently requires C++11
It's described in the C++ proposal ... lifecycle, stack must be managed + ownership and state (for instance resuming an already running fiber).
IMHO, fiber execution, and the fiber class itself, should be a separate library, which may require C++11. It was my understanding that this is what Boost.Coroutine and Boost.Coroutine2 are for. Boost.Context, on the other hand, would only contain low level code for saving and restoring thread context and nothing else. This kind functionality doesn't seem like dependent on C++11 features.