On 10 Sep 2014 at 20:09, Vicente J. Botet Escriba wrote:
Be aware that C++ 11, and especially C++ 17 as it currently is thought to become, consider future-promise as the sole way for i/o completion handlers to be invoked via the new future<T>.then(callable) function. In particular, 17's resumable function support *requires* that the function must return a future, so if you want language based coroutine support, you must use future<T>. Niall, C++17 is not done. There is a paper generalizing resumable functions, so that they can return other types than future<T>. This is very interesting, as it could be used also for expected<T,E>. The promise/future you are working on could be used also :)
Ah, my hope would be that the expected<T, E> based future becomes the standard future. It would be enormously more efficient if we can avoid the memory allocator, if not the cmpxchg instruction. That said Vicente, right now I am trying to port expected<T, E> to VS14 CTP 3. Oh the joys of internal compiler errors!
As much as Chris and many ASIO users are opposed to that design choice, we must play with the hand we have been dealt by WG21. I will say that future-promise can be made constexpr and no-alloc, and that makes an awful lot of the inefficiency go away, though an implicit synchronisation is unavoidable as .then() must check if the operation has already completed. Again nothing is fixed. Things evolve, and we don't know yet what the next concurrency TS will contain.
Very true. My statements were made in case though focusing on ASIO were not fully aware of what I meant by a C++ 14 based approach i.e. quite some change over current practice. I have been ruminating with Louis Dionne about how best to model an asynchronous i/o monad using expected<T, E>. It is proving mind hurty. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/