P2052: Making modern C++ i/o a consistent API experience from bottom to top


The 2019 Cologne meeting highlighted that multiple approaches and design philosophies to asyn-chronicity and i/o were beginning to ‘butt heads’ against one another. The 2019 Belfast meeting found unexpected committee support for the low level file i/o proposal [P1883] file_handle and mapped_file_handle, with much feedback being received that many would like to see a similar low level API treatment of non-file i/o. It was noted again during the second discussion of [P1750] A Proposal to Add Process Management to the C++ Standard Library that most of P1750 deals with i/o rather than processes, because nowhere else in the standard deals with the pipe i/o required to speak stdin, stdout and stderr to child processes.

Straight after the Belfast meeting I had an email discussion with all the major modern i/o players on WG21, during which I proposed building a consistent low level i/o API framework capable of solving everybody’s use cases, while also being compatible with Sender-Receiver, and specifically designed so a Networking TS implementation could be wholly constructed from it. If successful, we would have a path forwards via which all modern i/o in the future C++ standard could be made a consistent experience for C++ developers, whilst retaining flexibility of composure and genericity, but also with low level i/o’s strong guarantees of propagating the i/o determinism characteristics of the underlying platform.

Due to limits on free time, the prototype only implements pipe_handle. Due to surprise at the diÿculty of matching ASIO’s performance, which required several complete redesigns to achieve which were time-costly, by the time this paper was written the prototype only works on Microsoft Windows, and only in single threaded configuration. The recommendations made by this paper ought to be coloured appropriately.


Stay in touch