3 回答
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_future
vsstd::future
)参数传递的语义
std::thread
不同于boost::thread
--- Boost使用boost::bind
,后者需要可复制的参数。std::thread
允许将仅移动类型std::unique_ptr
作为参数传递。由于使用boost::bind
,占位符的语义(例如_1
嵌套绑定表达式中的语义)也可以不同。如果您未明确调用
join()
,detach()
则boost::thread
析构函数和赋值运算符将调用detach()
要销毁/分配给的线程对象。对于C ++ 11std::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,但这仍然是一个依赖项。
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
。
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。
- 3 回答
- 0 关注
- 810 浏览
添加回答
举报