谷歌C++编码风格,没有例外规则.多线程怎么样？

Question

Google C++编码风格建议不要使用C++异常,我们也不会使用它们.对于大多数STL库容器,可以忽略异常,因为通常它们表示严重错误并且难以处理,因此崩溃是可以接受的.

但是多线程(std :: thread)存在问题,例如,两次输入非递归互斥锁会引发异常.这种情况并不重要,可以通过等待来处理.

我的问题是:有谁知道Google使用什么作为线程库？是否有任何C++跨平台线程库不使用异常？

谢谢

Answer 1

应该注意的是,谷歌的风格指南并不排除处理例外而是排除异常.即处理问题,但不要因为抛出更多异常而使问题变得更糟.

在重新输入非递归互斥锁的情况下:这显然是一个程序员错误,而不是一些意外的蓝色螺栓.应允许异常传播到调用代码,以便可以将其视为错误处理.应该注意的是,Google Test框架不依赖于异常,但它肯定可以捕获并报告它们.

虽然谷歌的风格指南占据了一个极端的位置,但毫无疑问,在编写可重用的库时异常可能会出现问题.例如,我们发现使用WinCE 6.0进行开发时,在重新抛出时会出现异常,并且在ARM平台上无法可靠地抛出DLL边界.此外,捕获异常可能需要几毫秒,因此它们绝对不应用于需要实时性能的非特殊情况(即"预期"错误).这个名字的线索确实如此.

Answer 2

谷歌风格指南中的做法可以追溯到上个世纪九十年代早期,当时线程是相当异国情调的野兽.因此,想知道这种风格和线程如何混合是没有意义的.如果您使用线程等"现代"(21世纪)技术,则不要使用Google的样式指南,反之亦然.

Answer 3

IIRC之所以谷歌没有使用异常是因为他们的代码库中的大部分都不是异常安全的,并且他们无法承担重写的责任.

从他们的网站:

从表面上看,使用例外的好处超过了成本,特别是在新项目中.但是,对于现有代码,异常的引入会影响所有依赖代码.如果异常可以传播到新项目之外,那么将新项目集成到现有的无异常代码中也会出现问题.由于Google的大多数现有C++代码都没有准备好处理异常,因此采用生成异常的新代码相对比较困难.

鉴于Google的现有代码不能容忍异常,使用异常的成本比新项目的成本要高一些.转换过程缓慢且容易出错.我们不认为可用的异常替代方案(例如错误代码和断言)会带来很大的负担.

我们反对使用例外的建议不是基于哲学或道德理由,而是基于实际理由.因为我们想在Google上使用我们的开源项目,如果这些项目使用例外情况很难这样做,我们也需要针对Google开源项目中的例外情况提出建议.如果我们不得不从头再做一遍,事情可能会有所不同.