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

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

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.

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.

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.

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.