GCC9 Lands Initial C++ Networking TS Implementation

[ssokolow]

why does networking need special integration into the c++ programming language , not just the standard library ?

I haven't read the details, but I'm guessing that it's the difference between printf/scanf and iostream. The former is a C API with C idioms, while the latter is a C++ API with enhanced functionality and better integration with C++ idioms such as allowing any class to define its own iostream serialization so << myobject will Just Work™.

[patstew]

why does networking need special integration into the c++ programming language , not just the standard library ?

It is essentially a copy of boost::asio copied into the standard library. There's no change to the core language.

[F.Ultra]

I was working on a third party product built using Windows CE... 3? 4? I don't think the code shared much or maybe anything with the Windows 95+ and Windows NT+ source.

Windows CE 3.0 had full sockets support: https://msdn.microsoft.com/en-us/library/ms882980.aspx . While Microsoft had some C++ networking classes back then they where built on top of Winsocks so accept/listen/connect/send/recv is not compatibility layers even on Windows but the foundation (Winsock is the TCP/IP stack in Windows since 1994 and before that they had none, there existed third party ones but no from MS).

[Michael_S]

Windows CE 3.0 had full sockets support: https://msdn.microsoft.com/en-us/library/ms882980.aspx . While Microsoft had some C++ networking classes back then they where built on top of Winsocks so accept/listen/connect/send/recv is not compatibility layers even on Windows but the foundation (Winsock is the TCP/IP stack in Windows since 1994 and before that they had none, there existed third party ones but no from MS).

I stand corrected. Sorry for the misinformation.

[Haegar15]

POSIX and BSD Sockets are the standards, if you code to those standards your code is crossplattform. Even on Windows there are compatibility layers, unless you want to just plainly use MS Development Environments - but even there you have a compatibility layer nowadays (the functions are named eg _open instead of open, and a few other minor annoyances you can easily solve).

This is not true if you want to do it asynchronous and high-performance networking.
For good async networking you need to use IO-Completion-Ports on Windows. On Linux you have to use epoll. On BSD you have to use kqueue. All of those are not POSIX standards. POSIX way of doing async operations is the select-call, which scales absolutely terrible.

If you want to do async, scalable, high-performance networking on different OSes you have to use a lot of #ifdefs or use a library like Boost.Asio or something like the new Networking TS. I don't know what OS the GCC-folks are aiming for. I suspect Linux is the first candidate, but what about BSD/MacOS and Windows?

[AsuMagic]

why does networking need special integration into the c++ programming language , not just the standard library ?

https://gcc.gnu.org/git/?p=gcc.git;a..._source=anzwix

That's all in libstdc++.

edit: oh whoops didn't realize you got that answer 3 times already :P

[discordian]

This is not true if you want to do it asynchronous and high-performance networking.
For good async networking you need to use IO-Completion-Ports on Windows. On Linux you have to use epoll. On BSD you have to use kqueue. All of those are not POSIX standards. POSIX way of doing async operations is the select-call, which scales absolutely terrible.

If you want to do async, scalable, high-performance networking on different OSes you have to use a lot of #ifdefs or use a library like Boost.Asio or something like the new Networking TS.

You know, you left out the sentence in my post where I basically said that.

[coder]

On Linux you have to use epoll. On BSD you have to use kqueue.

Those are supplemental and complementary to the sockets API - not a replacement for - or alternative to.

I don't know what OS the GCC-folks are aiming for. I suspect Linux is the first candidate, but what about BSD/MacOS and Windows?

Boost.Asio supports all of those platforms. I guess they can't lift code with a Boost license, but they could just use _select() on Windows. Likewise, for BSD support could initially use select() or they could go straight for kqueue, but nearly everything aside from the io_service should be sharable with Linux.

[coder]

BTW, Linux really needs a proper async resolver, like one of these:

https://www.gnu.org/software/adns/

https://c-ares.haxx.se/

However, the problem with using a 3rd party library is that it doesn't play nicely with things like nss. This is why proper async lookups should be built-in - and not threading hacks like getaddrinfo_a() that don't scale.

[coder]

A network library does not belong in part of a programming languages standard library. This kind of "batteries included" approach taken by things like Java, C# and Javascript are sloppy.

Perhaps at one point in time, but I think the world is moving towards a more "batteries-included" model. Do you think C++ should include a threading library? What about filesystem? Do you feel it was a mistake to include stdio in C? I don't see such an obvious distinction between file I/O and networking.

That said, I think a graphics library is going too far, but it also seems to be on the way.

Anyway, it's worth pointing out that the new library supports a powerful, scalable event-driven programming model that you can even use for non-networking purposes. Another benefit of having this built right into the standard library is that we should see independent implementations of standard networking protocols that can be multiplexed together in the same io_context (i.e. driven by the same thread pool).

As it currently stands, if you want to integrate separate HTTP and RTSP libraries into your program, for instance, you likely must either drive them with different threads, or have some not insignificant amount of work to integrate them with your I/O multiplexing scheme of choice. This is definitely going to be an improvement.