Originally posted by GunpowaderGuy
View Post
Announcement
Collapse
No announcement yet.
GCC9 Lands Initial C++ Networking TS Implementation
Collapse
X
-
- Likes 1
-
-
Originally posted by Michael_S View Post
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.
- Likes 1
Comment
-
Originally posted by F.Ultra View Post
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).
- Likes 1
Comment
-
Originally posted by discordian View PostPOSIX 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).
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?
- Likes 2
Comment
-
Originally posted by GunpowaderGuy View Postwhy does networking need special integration into the c++ programming language , not just the standard library ?
That's all in libstdc++.
edit: oh whoops didn't realize you got that answer 3 times already :P
Comment
-
Originally posted by Haegar15 View Post
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.
Comment
-
Originally posted by Haegar15 View PostOn Linux you have to use epoll. On BSD you have to use kqueue.
Originally posted by Haegar15 View PostI 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?
Comment
-
BTW, Linux really needs a proper async resolver, like one of these:
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.
Comment
-
Originally posted by kpedersen View PostA 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.
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.Last edited by coder; 15 October 2018, 07:12 PM.
Comment
Comment