This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Networking TS implementation

On 18 October 2015 at 00:30, Jonathan Wakely <> wrote:
> On 17 October 2015 at 19:40, Mikhail Maltsev wrote:
>> On 10/17/2015 06:46 PM, Jonathan Wakely wrote:
>>> It's still missing socket iostreams, parts of the use_future
>>> completion token handling, and system_context needs some work
>>> (currently it uses a "thread pool" hardcoded to one thread).
>> Hi! I'm very interested in the networking part of the C++ standard, but
>> unfortunately could not find much information on it's current status.
> There is nothing in the standard, this is a proposed TS, which would
> be a separate document from the International Standard.
>> Perhaps you could help and shed some light on the situation:
>> 1. Do I understand correctly, that the library part (especially the API) is
>> mostly based on the asio [1] library?
> Yes.
>> 2. What about futures/promises, i.e. some facilities for chaining async_result-s
>> (IIUC, current std::future will not work well with asio Executor-s)? Will the
> See net::use_future in the proposal. It might not be clear if you're
> not familiar with the concepts, but you can pass net::use_future as a
> completion token, which will cause a std::future to be returned, so
> you can wait on that for the result. The completion handler itself can
> be used to chain further operations when the first one completes.
> If you want to chain std::future-type objects then see the draft
> Concurrency TS. I think
> is
> the most recent publicly-available draft.
>> standard eventually include something similar to tasks implemented in
>> Microsoft's casablanca (aka cpprestsdk) [2] or futures/promises in the seastar
>> library [3]?
> I don't know anything about cpprestsdk but you can use a custom
> completion token to return other types of future.
>> 3. What about resumable functions support in the language itself? Which
>> implementation is in favor? Is it N4134 [4]?
> There are competing proposals.
>> 4. How will all of the above work together?
> They might not. The point of publishing each piece of work as a
> separate TS is to get implementation experience and user feedback
> before anything is added to the standard and set in stone. The
> approach in one TS doesn't necessarily have to agree or interoperate
> with the approach in another TS. They are experimental ideas and are
> not intended to form a single, cohesive design.
> I have been working on the Networking TS, I'm not the best person to
> ask about the others.
> You can follow their status at

btw, the link in my original email has information relevant to all
your questions.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]