为了账号安全,请及时绑定邮箱和手机立即绑定

用c ++ 11等效项替换boost :: thread和boost :: mutex是否明智?

用c ++ 11等效项替换boost :: thread和boost :: mutex是否明智?

C++
小唯快跑啊 2020-02-04 16:14:21
动机:我正在考虑的原因是,我的天才项目经理认为boost是另一种依赖,并且它很可怕,因为“您依赖它”(我试图解释boost的质量,然后过了一段时间就放弃了:( )。我之所以愿意这样做的较小原因是我想学习c ++ 11的功能,因为人们将开始在其中编写代码。#include<thread> #include<mutex>和Boost等价物之间是否存在1:1映射?你会考虑一个好主意,以取代C ++ 11升压的东西的东西。我的用法是原始的,但是有没有一些示例说明std不提供什么功能呢?或者(亵渎)反之亦然?PS我使用海湾合作委员会,所以头在那里。
查看完整描述

3 回答

?
精慕HU

TA贡献1845条经验 获得超8个赞

Boost.Thread和C ++ 11标准线程库之间有一些区别:

  • Boost支持线程取消,C ++ 11线程不支持

  • C ++ 11支持std::async,但Boost不支持

  • Boost具有boost::shared_mutex用于多读者/单作家的锁定。类似的std::shared_timed_mutex仅可自C ++ 14(N3891),而std::shared_mutex仅可自C ++ 17(N4508)。

  • C ++ 11超时与Boost超时不同(尽管现在应该很快改变,现在Boost.Chrono已被接受)。

  • 一些名称是不同的(例如boost::unique_futurevs std::future

  • 参数传递的语义std::thread不同于boost::thread--- Boost使用boost::bind,后者需要可复制的参数。std::thread允许将仅移动类型std::unique_ptr作为参数传递。由于使用boost::bind,占位符的语义(例如_1嵌套绑定表达式中的语义)也可以不同。

  • 如果您未明确调用join()detach()boost::thread析构函数和赋值运算符将调用detach()要销毁/分配给的线程对象。对于C ++ 11 std::thread对象,这将导致std::terminate()对应用程序的调用并中止该应用程序。

为了阐明仅移动参数的要点,以下是有效的C ++ 11,并将所有权int从临时std::unique_ptr转移到f1新线程启动时的参数。但是,如果您使用boost::thread它,则它将无法使用,因为它在boost::bind内部使用,并且std::unique_ptr无法复制。GCC随附的C ++ 11线程库中还有一个错误,阻止了此工作,因为它std::bind也在实现中使用。

void f1(std::unique_ptr<int>);std::thread t1(f1,std::unique_ptr<int>(new int(42)));

如果使用的是Boost,那么如果您的编译器支持的话,您可能可以相对轻松地切换到C ++ 11线程(例如,Linux上的最新版本的GCC在-std=c++0x模式下可用的C ++ 11线程库的实现基本完整)。

如果您的编译器不支持C ++ 11线程,则您可能能够获得第三方实现,例如Just :: Thread,但这仍然是一个依赖项。


查看完整回答
反对 回复 2020-02-04
?
千巷猫影

TA贡献1829条经验 获得超7个赞

std::thread基本上是模仿的boost::thread,有一些区别

  • boost的不可复制的,一对一映射到一个OS线程的语义得以保留。但是该螺纹是可移动的,以允许从工厂功能返回螺纹并将其放入容器中。

  • 该提议为加上了取消功能boost::thread,这是一个很大的麻烦。此更改不仅对线程有很大影响,而且对C ++线程库的其余部分也有很大影响。据信,这种巨大的改变是有好处的,这是合理的。

    • 现在,线程析构函数必须在分离之前调用cancel,以避免在取消父线程时意外泄漏子线程。

    • 现在需要一个显式的分离成员来启用分离而不取消。

  • 线程句柄和线程标识的概念已分为两类(它们在中是同一类boost::thread)。这是为了支持更容易地操作和存储线程标识。

  • 添加了创建线程ID的功能,该线程ID保证没有其他可连接线程被比较(boost::thread不具有此功能)。这对于想要知道它是否由与先前调用相同的线程执行的代码非常方便(递归互斥是一个具体的示例)。

  • 存在一个获取本机线程句柄的“后门”,以便客户端可以根据需要使用基础操作系统来操纵线程。

这是从2007年开始的,因此某些要点不再有效:boost::thread现在具有native_handle功能,并且正如评论者所指出的,std::thread不再具有取消功能。

boost::mutex和之间找不到任何重大差异std::mutex


查看完整回答
反对 回复 2020-02-04
?
婷婷同学_

TA贡献1844条经验 获得超8个赞

企业案例

如果您正在为需要在中型到大型操作系统上运行的企业编写软件,并因此在这些操作系统上使用各种编译器和编译器版本(尤其是相对较旧的版本)进行构建,则我的建议是远离现在完全是C ++ 11。这意味着您不能使用std::thread,我建议您使用boost::thread

基本/技术启动案例

如果您正在为一个或两个操作系统编写程序,那么您肯定会知道只需要使用主要支持C ++ 11(例如VS2015,GCC 5.3,Xcode 7)的现代编译器进行编译,而您还没有取决于boost库,那么std::thread可能是一个不错的选择。

我的经验

我个人偏向于强化,频繁使用,高度兼容,高度一致的库,例如boost与非常现代的替代品。对于复杂的编程主题(例如线程)尤其如此。此外,我长期以来boost::thread在各种各样的环境,编译器,线程模型等方面都取得了巨大的成功(总体而言,也是boost)。当我选择它时,我选择boost。


查看完整回答
反对 回复 2020-02-04
  • 3 回答
  • 0 关注
  • 774 浏览

添加回答

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信