Subject: Re: [boost] C++ committee meeting report
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-06-27 08:08:58
On 24 Jun 2014 at 10:47, Beman Dawes wrote:
> * Shipped the File System TS for ISO DTS (i.e. final) ballot. Since it
> would be very unusual for at DTS ballot to fail, the File System TS is
> essentially done. The committee is now actively looking for File System TS
> 2 proposals. My work now shifts to bringing the Boost implementation into
> compliance.
Congrats on this Beman. To get a whole library conceptualised from
the beginning into the standard is an enormous commitment and
achievement, and one which couldn't have happened with you.
> * The Library Evolution Working Group (LEWG) voted to base the Networking
> TS on Boost.ASIO. That was a major surprise, as a Networking Study Group
> had been trying to build up a Networking TS from many small proposals. But
> in LEWG polls, support for ASIO was overwhelming, with no one at all voting
> against. This was a major vote of confidence for Boost.ASIO and Chris
> Kohlhoff. And several ASIO supporters were not even in the room at the time
> because Filesystem issues were being worked on elsewhere.
This is an enormous dose of common sense, and I applaud it. Anyone
who has used ASIO to any extent will find complaint with its
implementation, documentation and occasionally design, but it is
unquestionably and categorically the standard go-to library for C++
for anything involving async. It may be warty, but it has become the
common practice.
Now a subset of it will become the standard networking library, I
hope that all other async proposals before the committee can be
amended to assume its existence, and that those async proposals -
especially those from proprietary vendors based on their proprietary
platform technologies - which can't or won't fit ASIO should be
discarded from consideration immediately.
Vicente, Pierre and others have been working on a generic monadic
continuations framework which will enable seamless interoperation of
all things async, such that one could mix together futures, ASIO
callbacks, Fiber coroutines and anything else async including
proprietary vendor technologies if they choose. I'll be helping them
out with hopefully a malloc-free promise/future implementation which
uses that framework if I can get such a thing working - this would
reduce promise/future to merely a specialised subset use of the
monadic framework. If I get that working, I'll next integrate it into
ASIO and AFIO so at least those three libraries all have
interoperable continuations with general threading.
Obviously, I haven't got it written yet, so I make no promises. I'm
currently investigating how best to use memory transactions in the
implementation and whether supporting transactional GCC is worth it.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/