Why Asio?

(点击 上方公众号 ,可快速关注)

Asio系列文章开写了,希望大家关注。

Asio库大概率会进入 C++23 标准库,是时候该学习一下了。

长久以来,C++最饱受诟病的一点就是缺少一些实用的库,比如,网络库、文件系统、日期库等。而网络库是我们平时最常用的库之一,现在的软件基本上都离不开它。所以有一套标准的网络库是多么的重要,开箱即用,不用在那么多的三方库中做选择,甚至也不用自己实现。

从目前进度来看, Asio 进入C++标准库只是时间问题,大概率会进入 C++23 。最新的提案是2018-10-08的n4771,包含的功能只是目前 Asio 库的子集,后续进入标准库时极有可能增加一些其他功能,比如,将 boost.beast 库加进去,使标准库支持 http/https/websocket 协议。所以,在后续选择网络库的时候应该提高 Asio 库的优先级,这样可以在后续平滑切换到标准库。

优点

与其说 Asio 的优点,不如说标准库的优点。凡是能入C++标准库的,都有以下几个优点:

  • 跨平台

    网络库如果只针对某个平台,会极大限制软件向其他平台迁移。这种例子很多,如早期的服务软件使用了Windows下的软件API,后续想迁移到Linux平台,这个迁移成本是很大的,Api的替换只是工作的一部分,大部分的工作是兼容性、稳定性的测试。

    Windows下的socket api虽说和Linux下的socket api大同小异,但高性能的服务器编程用到的其他工具,如定时器、异步、同步等机制都是不同的,迁移成本也是很高的。

    所以,尽可能选择跨平台的网络库,为以后留下变化空间。

  • 扩展性

    标准库被设计为其他上层工具的组件,必须要有足够的扩展性。

    横向地说,虽说Asio现在只支持tcp、udp等协议,但通过扩展也可以支持其他协议。

    纵向地说,Asio已经支持了常用地socket 选项,但保留了扩展的能力,后续可以支持更多的选项。

    相比而言,很多轮子的扩展性就一般了,尤其是很多公司内部造的轮子。

  • 性能不错

    既然能进标准库,性能肯定不错,所以不要有疑问。而且,相信进入标准库后会有更大程度的优化。

  • 无维护成本

    写一个网络库简单,但维护它就是另外一个话题了。很多个人或公司并没有足够的维护自己造的轮子,导致库停滞不前,成为废库,bug、安全漏洞没人修复。

这里并不是说Asio就是万能的,能进标准库,说明能解决绝大部分情况的问题,肯定有一些特殊的情况还是需要自己重新造轮子,这里只是希望能在造轮子之前先考虑以下Asio。

误解

实际上去年在技术选型阶段,我调研过 Asio 库,但看到网上很多评论对它的负面评价,所以并没有使用它。直到今年在进行了一番尝试之后才在正式项目中使用。

网上主要有几个观点:

  • 不喜欢 Asio 风格,模板大量使用,代码不易阅读

    准确讲,这不是Asio的缺点,这是C++模板的问题,现在C++标准库的工具都有类似的问题。模板赐予C++更大的表现力,这是不争的事实,两者权衡取其轻,不能因为一些缺点就全盘否定模板。

    好的是,随着concept等工具进入C++,后续模板的一些问题会慢慢得到解决。

  • Asio很慢

    这点一开始我还真信了,但通过自己的使用和一些专业的评测结果,实际上这一点子虚乌有的。如果性能真的差很多,只能说明自己的用法不对。抽象会伴随性能的些许降低,但正常情况下不会引起性能陡降。

  • Asio依赖 boost

    Asio目前有三种载体,单独的Asio库,和boost捆绑在一起,提案的参考实现。可以看到,Asio是可以脱离boost的,你不必把整个boost引入。而且,以后进入标准库了,开箱即用,就更跟 boost 没关系了。

  • 已经有 libeventlibevlibuv 了,不需要 Asio

    不可否认,它们三者都是优秀的网络库,但它们都是基于 C 语言的。 C++ 在抽象程度上是远远高于 C 的,这决定了同等能力的库,基于 C++ 的库使用更简单,更不易出错。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章