On 30 Jun 2014 at 10:19, Gary Powell wrote:
While having a library in the standard isn't required to use it, it's so nice to have things like the File system standardized as well as building tools like Any and Optional and now ASIO.
I think the wicked hard problem with ASIO will be deciding what subset of it to standardise. For example, I would wonder if strands or coroutines or any of the Windows support would make it. There is also a strong argument that anything in ASIO which isn't async needs to go. Plus, some might feel that ASIO's current design uses too much malloc for embedded systems/ultra low latency, and I would sympathise :) Finally, as a personal viewpoint I don't care much for ASIO's internal implementation. I find it obtuse and hard to debug or indeed figure out much at all as bits of implementation are scattered all over the place. Some if not much of that is because ASIO implements a sort of generic concept type framework all of which requires checking, well the obvious course of action here is to use proper C++ 17 concepts and do away with the legacy design cruft. I'd also personally split the genericity away from the implementation, and push the implementation into a non-header built stable ABI so we can avoid pulling in so many system header files like all of windows.h. Lastly, as I mentioned before we really need ASIO as a task executor to do continuations easily into threading, futures etc and vice versa so one can easily chain network with disc with thread messaging i/o and so on. I can already see others having vehement disagreements in the above :) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/