Will (and should) there be sockets in C++11?

c++ sockets c++11

35,518

Solution 1

No, it is not. As for the near future, the C++ standards committee has created a study group that is developing a networking layer proposal. It looks like they're going for a bottom-up approach, starting with a basic socket layer, then building HTTP/etc support on top of that. They're looking to present the basic socket proposal at the October committee meeting.

As for why they didn't put this into C++11, that is purely speculative.

If you want my opinion on the matter, it's for this reason.

If you are making a program that does something, that has a specific functionality to it, then you can pick libraries for one of two reasons. One reason is because that library does something that is necessary to implement your code. And the other is because it does something that is helpful in implementing code in general.

It is very difficult for a design for a particular program to say, "I absolutely must use a std::vector to hold this list of items!" The design for a program isn't that specific. If you're making a web browser, the idea of a browser doesn't care if it holds its tabs in a std::vector, std::list, or a user-created object. Now, some design can strongly suggest certain data structures. But rarely does the design say explicitly that something low-level like a std::list is utterly essential.

std::list could be used in just about any program. As can std::vector, std::deque, etc.

However, if you're making a web browser, bottled within that design is networking. You must either use a networking library or write a networking layer yourself. It is a fundamental requirement of the idea.

The term I use for the former type, for libraries that could be used in anything, is "utility" libraries.

Threading is a utility library. Design might encourage threading through the need to respond to the user, but there are ways to be responsive without preemptive multithreading. Therefore, in most cases, threading is an implementation choice. Threading is therefore a utility.

Networking is not. You only use networking if your design specifically calls for it. You don't decide to just dump networking into a program. It isn't an implementation detail; it is a design requirement.

It is my opinion that the standard C/C++ library should only implement utilities. It's also why I'm against other heavyweight ideas like XML parsers, etc. It isn't wrong for other libraries to have these things, but for C and C++, these are not good choices.

Solution 2

I think it should, since a lot of other popular languages support socket operations as a part of the language (they don't force the user to use any OS-specific API). If we already have file streams to read/write local files, I don't see why we can't have some method of transferring data with sockets.

Solution 3

There will be no sockets in C++11. The difference between threads and sockets is that threads involves making more guarantees about ordering, if your program involves threads. For a platform with just one core, then C++11 doesn't mandate that your CPU springs an extra core. Sockets, on the other hand, would be... difficult to implement portably and fail gracefully on systems that don't have them.

Solution 4

There will not be in C++0x. There are proposals to add them in a future version.

The amount of new stuff in C++0x had to be limited to give the committee time to deal with it all thoroughly.

Solution 5

This is so weird that in 2020, there is still no standard for a basic OS construct as sockets in C++.

The closest I found is kissnet (Apparently exists since 2019).

It's small (~1700 lines), runs on Windows and Linux, uses OpenSSL, and requires C++ 17 (Which is a plus in my book), basically everything I needed.

View more solutions

35,518

Author by

thomasvakili

I'm a PhD student at the Department of Computer and Systems Sciences at Stockholm University. I am researching have to train machine learning models while protecting the privacy of people in the training datasets. I have an MSc in Computer Science and Engineering from KTH - Royal Institute of Technology. Before starting my PhD, I worked as an IT-consultant with backend and data engineering and have experience in multiple languages. My languages of choice are Scala, Python and Java.

Updated on April 21, 2020

Comments

thomasvakili about 4 years

Is the new C++11 going to contain any socket library? So that one could do something std::socket-ish?

Seeing as how std::thread will be added, it feels as if sockets should be added as well. C-style sockets are a pain... They feel extremely counter-intuitive.

Anyways: Will there be C++ sockets in C++11 (googled it but couldn't find an answer)? If not, are their any plans on adding this? Why (/ why not)?
thomasvakili almost 13 years

Great answer, although I don't agree with you. Seeing as C++ is basically C with classes I think it should include some of the stuff provided by C but in a OOP format. Especially something as useful as sockets. Because non-OOP sockets are really, really painful.
Nicol Bolas almost 13 years

@Touzen: Since when did the C-standard library come with sockets? Not even C1x is slated to support them in the standard library.
thomasvakili almost 13 years

I'm just saying that the fact that they haven't been included before is not a good enough argument to exclude them. Seeing as how C++ is OOP-based, it should support OOP-sockets. It'd make network programming a whole lot easier and understandable.
Nicol Bolas almost 13 years

@Touzen: I didn't make the argument that it shouldn't be included because it wasn't included before. I made the argument that it shouldn't be included because it is not an appropriate subject for the standard C++ library. And if you want a C++ implementation of networking, it already exists. Boost has a networking library. Just use that.
Ben Voigt almost 13 years

@Touzen: C++ does support OOP-socket. Just add a C++ sockets library. Similar to the way you have to add a flat sockets library to C.
MSalters almost 13 years

Disagree with the "fail gracefully". A machine with no network card doesn't really differ from a machine with no network cable. You have to implement the library such that "no network connection" is a representable state.
deft_code almost 13 years

@Touzen: be careful "basically C with classes" is most often used to describe bad C++ code. C# and Java are much more similar to each other than either is to C++. C++'s templates and much of the standard library are unique among programming languages (except for D which is strongly influenced by C++). Their correct use lends to code styles that purely OOP languages cannot support.
RogerV almost 13 years

It's all nice and fine to make philosophical justifications for leaving things out of std:: but the pragmatic reality is that C++ (and now C++0x) continues to suffer in comparison to C# .NET, Java, Python, and others, in not having a larger set of off the shelf solutions for the problems that developers are typically addressing in their applications. There is a huge lift bestowed on developers by the breadth of what's in, say, the Java SE by default.
Nicol Bolas almost 13 years

@RogerV: Why does a solution have to be a part of the standard library to be "off the shelf?" In what way is Boost, LibXML2, etc, not part of the "shelf" of C++ programming? What is wrong with going out and grabbing a library to accomplish a particular task? Said library will be designed and written by experts in those fields, not amateurs. I simply do not understand this apparent belief of some people that, if it's not bundled with the compiler, it doesn't exist or it is somehow less important. I prefer expanding my shelf and letting the standard library be for generic utilities.
RogerV almost 13 years

Once functionality is in the language standard library then its incumbent upon the language implementors to provide it. So whereever that standard of the language appears so to will be that standard library spec. Whereas the 3rd party library folks may not port their respective libraries to all the platforms that the language appears on. After decades of industry experience there's a pretty good basis of what is good for consolidation into a standard library. Java, .NET, Python give their devs a leg up in no small part because of how much there is to leverage from their standard class libs.
Nicol Bolas almost 13 years

@RogerV: There is only one official language implementation for each of those examples: one official Python distro, one official Java distro, and one official .NET distro. While there are some unofficial ones, there's a single one that is definitive. If the makers of the official distro don't deem your platform worthy of a port, you're SOL. Due in part to the smaller standard libs, a C++ port is much easier. Any given C++ library may work fine without fixes, and the fixes may be only minor. Plus, there are plenty of libraries in C++; if one doesn't work, another one may. Bazaar > Cathedral.
Mushy about 11 years

What about Boost? It is designed and implemented by member of the standards committee for c++ and will likely be incorporated into std (instead of boost::asio, std::asio). The boost library contains much more than utilitarian functionality and implements core functionality of other languages such as Java. I very much desire boost become a part of c++.
Nicol Bolas about 11 years

@Mushy: Howevermuch you may desire it, it's not going to happen. Boost as a whole will never become part of C++. Parts of it will be, but even those will get changes as they enter the standard. Even Asio is not being taken directly (and Asio is really a separate project released under the Boost banner).
Rahly over 9 years

Sorry, but in this day and age, I say networking is fundamental. Yes, you can use libraries, but something as basic as this should be included in the basic package. Now I think the browser reference would be more apt, if you had said "render engine" or "scripting engine" rather than networking. I don't think I've written software in the last 15 years that didn't require some level of networking. Even something as simple as "Check for Updates". Personally, I think one thing that C++ needs is first level support for sockets before it can be truly meaningful to most programmers.
mucaho about 8 years

Basic networking is part of basic I/O and that should be provided without libraries. Leaving out sockets is like leaving out the ability to operate on files in my opinion. Plus it's something system specific, whereas a XML parser does not generally rely on the underlying platform.
kakyo over 4 years

This answer is self-contained and makes a good engineering standpoint, but also a good example of discrepancy between engineering purity and user expectations: Users just want to get their jobs done faster, deploy their work easily to every platform, and maintain the least number of third-party dependencies.
ljleb over 3 years

Is there any other library like kissnet that is as easy to use and cross-platform? I don't know how to discover this kind of information efficiently.
Jay over 3 years

What platform are you missing?
ljleb over 3 years

I'm not saying that kissnet isn't cross-platform (because it is, the emphasis might have been misleading), I'm just wondering how I'm supposed to discover this kind of library myself. I've been looking for a good socket library for quite some time, and only by chance did I find your answer at some thinly related SO question.