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

Question

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)?

Candelaria

What do you find so difficult about the BSD sockets API? – Toady

Take a look at Boost.Asio. – Xymenes

@Ben: Well it just feels counterintuitive. And I like being able to use OOP when I'm in an OOP-language. – Candelaria

C++ is not an OOP-language. OO is one of the paradigms C++ supports as well as functional, procedural, generic (templates), etc. It sounds like a nit pick but once you really grok that c++ isn't an OOP-language your code will get a lot better. For instance ASIO is thought to be the best networking library available for C++. It is kinda OO, but really it's spread among all the paradigms. – Modulation

@deft_code: C++ does not really support functional paradigms. In fact its "support" is just plain lousy. That's like saying C supports OO. It doesn't, but that won't stop people from emulating OO practices with it. – Manheim

There is a site listing experimental technical specifications for (optional) extensions to the standard library, networking is one of these TSs - http://en.cppreference.com/w/cpp/experimental – Coth

2020 still no sockets in standard. This is a joke – Monsignor

Answer 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.

Dissidence

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. – Candelaria

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

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. – Candelaria

@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. – Dissidence

@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. – Toady

@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. – Modulation

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. – Ananias

@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. – Dissidence

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. – Ananias

@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. – Dissidence

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++. – Appreciation

@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). – Dissidence

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. – Caiman

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. – Coth

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. – Involucrum

Answer 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.

Unreserved

Answer 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.

Wool

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. – Quartan

Answer 4

This is so weird that in 2022, 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 (~1500 lines), runs on Windows and Linux, uses OpenSSL, and requires C++ 17 (Which is a plus in my book), basically everything I needed.

Filicide

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. – Differentiable

What platform are you missing? – Filicide

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. – Differentiable

libcurl seems fine to me. – Misdemeanor

Answer 5

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.

Toady

Answer 6

The wikipedia page for C++0x is usually pretty up to date and the section on library changes doesn't seem to mention sockets.

Komsa