[thread] Promote detail::invoke
Boost.Thread has a great implementation of `invoke` in it's detail namespace. I would like to see this moved outside of Threads, so that other libraries can benefit from it (or course, only if Vicente thinks this is ok). This seems like an ideal candidate for the Detail submodule, as several other libraries have a need for this piece of functionality. The implementation relies on `BOOST_THREAD_[RV|FWD]_REF`, which could be replaced by `BOOST_[RV|FWD]_REF`. This would mean introducing a dependency on Boost.Move, but I'll leave those details to the people leading the modularization effort. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
Le 16/06/14 06:47, Agustín K-ballo Bergé a écrit :
Boost.Thread has a great implementation of `invoke` in it's detail namespace. I would like to see this moved outside of Threads, so that other libraries can benefit from it (or course, only if Vicente thinks this is ok). This seems like an ideal candidate for the Detail submodule, as several other libraries have a need for this piece of functionality.
Hi Agustín, which library would make use of this function? The major problem with the current implementation is that there are a lot of corner cases and restrictions for C++98 compilers.
The implementation relies on `BOOST_THREAD_[RV|FWD]_REF`, which could be replaced by `BOOST_[RV|FWD]_REF`.
The current state of Boost.Thread (version 2 the default one) needs these thread specific `BOOST_THREAD_[RV|FWD]_REF` macros to adapt to the Boost.Thread specific emulation on version 2, and so if the invoke function in detail don't uses them Boost.Thread could not use it :( Agustín, as Boost.Thread would not profit of this (at least not immediately), would you mind to do the changes and maintain it?
This would mean introducing a dependency on Boost.Move, but I'll leave those details to the people leading the modularization effort.
Regards, The current state of the dependencies is
detail 4 -> config0 core2 mpl3 preprocessor0 static_assert1 type_traits3 move 4 ->config0 core2 mpl3 type_traits3 That means that if we add invoke to the detail module the dependencies of detail will increase of one level detail 5 ->config0 core2 move4 mpl3 preprocessor0 static_assert1 type_traits3 I don't think this would be a problem as we don't add cycles. Best, Vicente
On 16/06/2014 02:16 a.m., Vicente J. Botet Escriba wrote:
Le 16/06/14 06:47, Agustín K-ballo Bergé a écrit :
Boost.Thread has a great implementation of `invoke` in it's detail namespace. I would like to see this moved outside of Threads, so that other libraries can benefit from it (or course, only if Vicente thinks this is ok). This seems like an ideal candidate for the Detail submodule, as several other libraries have a need for this piece of functionality.
Hi Agustín,
which library would make use of this function?
From the top of my head, libraries that *could* make use of this function are: Function, Bind, Thread, Coroutine?, (upcoming) Fiber, Fusion, Phoenix, Spirit... Whether those libraries *would* make use of it, I don't know. I suspect that most would want to as they start working on C++11 support. I for one would like a consistent handling of Callables whenever it makes sense.
The major problem with the current implementation is that there are a lot of corner cases and restrictions for C++98 compilers.
That's to be expected.
The implementation relies on `BOOST_THREAD_[RV|FWD]_REF`, which could be replaced by `BOOST_[RV|FWD]_REF`. The current state of Boost.Thread (version 2 the default one) needs these thread specific `BOOST_THREAD_[RV|FWD]_REF` macros to adapt to the Boost.Thread specific emulation on version 2, and so if the invoke function in detail don't uses them Boost.Thread could not use it :(
I've missed that in my quick search.
Agustín, as Boost.Thread would not profit of this (at least not immediately), would you mind to do the changes and maintain it?
This is unfortunate, as my goal is to avoid libraries reimplementing this since it takes a lot of work to implement `invoke` for anything but a highly compliant C++11 compiler. If there is enough interest, I would gladly adapt it and maintain it. I have some experience with it; I have implemented and currently maintain a C++03 "with rvalue-refs" version of it here: https://github.com/K-ballo/hpx/blob/master/hpx/util/invoke.hpp and a C++11 one here: https://github.com/eggs-cpp/tupleware/blob/draft/include/eggs/tupleware/deta... Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
participants (2)
-
Agustín K-ballo Bergé -
Vicente J. Botet Escriba