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 17:28, Mikhail Maltsev wrote:
> Again, I'll look at the TS in more detail to see, how to implement that and to
> understand all the caveats. For now I got an impression that such implementation
> is also possible (and not too hard) with some custom CompletionToken-s, I'll try
> to experiment with it.

I thin it's doable, but I'm not sure how. I'll talk to the author
about it when I see him later today.

> But in order to start we need some implementation to work on. You mentioned that
> you have some prototype for Networking TS. Could you share it? FWIW, it should
> have some differences with asio (e.g., const_buffers_1 and mutable_buffers_1
> have been dropped).

Yes, I've implemented the proposal I linked to, not Asio.

I'll probably commit it to GCC trunk later this week if there are no objections.

> And another important question is: now hard is it to get some changes integrated
> into the upstream? It's fairly easy with GCC: I send a patch, the maintainers
> review it, if they find it reasonable, I fix their remarks and eventually commit
> it. IIUC, the process is the same with the TS implementation.

The TS implementation I'm talking about is going to be part of GCC, it
will have the same process as the rest of GCC (although as noted for
the Filesystem TS at
the API and ABI may be less stable, and so it might be easier to make
breaking changes than for the rest of libstdc++).

> But what about the TS API? Will it require much more bureaucracy? How large is
> the group of "decision makers" (i.e. the folks who eventually decide what goes
> in and what does not)?

It's going through a similar process as the C++ standard, but the
output is a separate document, not part of the standard. Due to the
experimental nature of a TS people are a bit more willing to put
things in that might not be perfect, because we can revise a TS a bit
easier than the standard, and we are not obliged to include anything
from a TS in the standard.

The committee meetings have 100+ people, and far more participating in
email discussions, but not all of them participate in the sub-groups
dealing with the Networking TS (which have generally happened in the
Library Evolution Working Group so far). See for more information
on the committee etc.

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