将(而且应该)在C + + 11中有套接字?
新的C ++ 11将包含任何套接字库? 所以可以做一些std::socket
-ish?
看到如何添加std::thread
,感觉好像套接字也应该被添加。 C型sockets是一种痛苦…他们感觉非常不直观。
不pipe怎样:C ++ 11中是否会有C ++套接字(使用Googlesearch,但无法find答案)? 如果没有,他们是否有任何计划join? 为什么(为什么不)?
不它不是。 就不久的将来,C ++标准委员会已经成立了一个研究小组,正在制定一个networking层提案 。 看起来他们正在采取自下而上的方法,从一个基本的套接字层开始,然后在其上构buildHTTP / etc支持。 他们希望在十月份的委员会会议上提出基本的套接字build议。
至于他们为什么不把它放到C ++ 11中,那纯粹是推测性的。
如果你想要我的意见,就是这个原因。
如果你正在做一个程序来做一些事情,那么它有一个特定的function,那么你可以select一个库来解决以下两个问题。 一个原因是因为这个库做了一些实现你的代码所必需的东西。 另一个是因为它做了一些有助于实现代码的东西。
一个特定程序的devise很难说:“我绝对必须使用std::vector
来保存这个项目列表!” 程序的devise不是那么具体。 如果你正在创build一个Web浏览器,浏览器的想法并不在意它是否在std::vector
, std::list
或者用户创build的对象中包含它的标签。 现在,一些devise可以强烈build议某些数据结构。 但是很less有devise明确表示像std::list
这样的底层是非常重要的。
std::list
可以在任何程序中使用。 可以std::vector
, std::deque
等
但是,如果您正在制作networking浏览器,那么在该devise中装入的是networking 。 您必须使用networking库或自己编写networking层。 这是这个想法的基本要求。
我用于前一种types的术语,即可用于任何事物的图书馆是“实用”图书馆。
线程是一个实用程序库。 devise可能会鼓励线程通过响应用户的需求,但是有一些方法可以在没有抢先式multithreading的情况下进行响应。 因此,在大多数情况下,线程是一个实现的select。 线程因此是一个实用程序。
networking不是 。 如果你的devise专门要求,你只能使用networking。 你不会决定只是将networking转储到一个程序中。 这不是一个实现细节; 这是一个devise要求。
我认为标准的C / C ++库应该只实现实用程序。 这也是为什么我反对像XMLparsing器等重量级的想法。其他库有这些东西是没有错的,但对于C和C ++,这些不是好的select。
我认为它应该,因为许多其他stream行的语言支持套接字操作作为语言的一部分(他们不强迫用户使用任何特定于操作系统的API)。 如果我们已经有文件stream来读取/写入本地文件,我不明白为什么我们不能有一些使用套接字传输数据的方法。
在C ++ 11中将没有套接字。 线程和套接字之间的区别在于, 如果程序涉及线程, 那么线程会涉及更多关于sorting的保证。 对于只有一个核心的平台,C ++ 11并不要求你的CPUpopup一个额外的核心。 另一方面,套接字将难以轻易实现,并且在没有套接字的系统上优雅地失败。
不会在C ++ 0x。 有提议将其添加到未来版本中。
在C ++ 0x中的新东西的数量不得不被限制在给委员会充分处理的时间。
C ++ 0x的维基百科页面通常是最新的,库变化部分似乎没有提到套接字。