C++0x - 导出已消失，异常规范已弃用。这会影响你的代码吗？ [关闭]

Posted 2023-02-16

【中文标题】C++0x - 导出已消失，异常规范已弃用。这会影响你的代码吗？ [关闭]

【英文标题】：C++0x - export gone, exception specs deprecated. Will this affect your code? [closed]

【发布时间】：2010-03-14 10:51:58

【问题描述】：

关于 C++0x 标准化过程的最新 Herb Sutter trip report 表明委员会已决定完全放弃模板的“导出”概念，并弃用异常规范。

我认为这些都是不错的举措，但我很想知道是否有人有一个代码库，这些更改会导致他们彻夜难眠？

【问题讨论】：

我很难回答“不会因为我不是用 C++ 开发”的冲动...

@Pavel 那么为什么不将“C++”添加到您的“忽略标签”列表中，那么您就不需要查看问题了？

完全删除导出当然是一个惊喜。几乎可以肯定这是正确的举动，但比我想象的要大胆得多。

@jalf：我完全同意。太糟糕了，他们没有或不能深六vector<bool>。

@David：请详细说明。 （文章链接会很棒。）仅阅读您的评论就让我认为我应该用vector<char> 或类似符号表示位向量，这似乎很荒谬。

【参考方案1】：

我从 cfront 1.0 开始就一直在使用 C++ 编程，我很高兴地说我从未编写过异常规范，也从未允许在我负责的代码中使用异常规范。当他们被提议时，我打电话给 Bjarne Stroustrup 并喊道：“不要这样做！”我给出了为什么它们是一个可怕的想法的所有原因。令我惊讶的是，他说了类似的话，“我知道。”当我问为什么来自 Hades 的功能进入规范时，他说有一个大玩家，他的“专家”坚决坚持必须进入规范，否则他们绝对不会签署，期间，结束讨论.如果我知道那是谁，我已经忘记了。

我已经弃用了很长时间。 :-)

【参考方案2】：

在过去的 5 到 6 年中，我参与的任何代码库肯定都没有不眠之夜。我想我从来没有遇到过使用 export 的人，而且像 Herb Sutter 这样的专家长期以来一直在反对异常规范（除了 nothrow），以至于大多数程序员现在都明白了。

【参考方案3】：

export 从未在 gcc 或 MSVC 中正确实现，（但显然在 EDG/Comeau 中是如此，正如 cmets 所说），但我猜它从未得到广泛接受。 （但我主要生活在 gcc/msvc 的世界里，所以我的观点并不包含整个 C++ 社区。）

至于异常规范，我相信它们也被破坏了。

第三，弃用并不意味着会导致编译器错误。只是强烈建议用户不要使用它，如果适用（我认为这里不是那么多），请转向其他机制以实现相同的目标。

【讨论】：

export 在 EDG 的前端实现。是否有任何迹象表明它没有正确实施？

@Marcus，除了 EDGs 前端，Comeau 完全实现了导出。

有人必须向我解释一下如何实现导出，而不需要创建一个中间预解析但未编译的语言进入目标文件。

@gf。据我了解，Comeau 使用 EDG 前端。

@Nemanja，我没有说什么不同的，不是吗？

【参考方案4】：

我当然不会对异常规范掉以轻心。 （“一个好主意，不幸的是，从来没有成功过。”）他们所擅长的只是现在noexcept 所代表的东西。

但我曾希望export 能成功。至少，export 将允许您更改模板的辅助函数，而无需使用这些模板重新编译所有代码。它会让我们摆脱所有detail 命名空间：

namespace detail  // actually we don't want this public, but can't avoid it
  template<typename T>
  void f_helper()  /*---*/ 


template<typename T>
void f() detail::f_helper();

void g() f<int>(); // has to recompile if f_helper()'s implementation changes

唉，因为我在过去十年中必须使用的编译器中只有一个实现了它，所以我永远无法使用它。

【讨论】：

export 的问题在于实现起来非常复杂，而且据我所知，语义并没有希望的那么有用。我从来没有真正研究过它（因为每个人都只是说“不要使用”），但从我所听到和阅读的内容来看，它并没有看起来那么有用。也许其他人可以详细说明？

@jalf：我也没有使用过，但我认为这取决于您所说的“有用”是什么意思。有些人可能认为这意味着“我不必在我的库中提供模板的源代码，只需提供二进制文件”，并感到非常失望。但是 sbi 说，“我不必每次更改模板时都重新编译那么多代码”，这对我来说听起来很对。当然，您仍然需要重新链接，并且可能链接导出的模板比链接已编译的类要慢。所以也许没有避免重新编译非模板代码的好处？

@Steve 和@jalf：正如我所说，我自己没有使用过export，但是，ISTR Daveed Vandervorde（EDG 的）声称它确实减少了周转时间，因为它可以防止重新编译由于在我的示例中更改间接使用的代码。当您修改大量使用的模板代码时（例如，templog.org - 日志库通常几乎无处不在），编译时间可能会成为主要的 PITA。

是的，在您的特定示例中，我相信您可以通过在某处显式实例化 f_helper<int> 并使用 extern 声明在 g() 翻译单元中引用它来加速 C++0x 中的编译对于那个实例化。这意味着g() 总是链接到另一个 T.U，所以虽然你的构建系统仍然会在模板更改时重新编译它，但至少它不必实例化模板，使用 f<int> 的其他 76 个 TU 也不会.不过，仍然相当痛苦，需要每个实例化而不是每个模板。

@Steve：虽然这在我的小示例中可能有效，但在实际项目中却行不通，因为在实际项目中，您有成千上万个这样的助手实例化了谁知道什么参数。想象一些模板元的东西 - 谁会去找出复杂的编译时列表真正实例化的模板参数......不不，防止它的间接用户不得不重新编译将是一个非常好的功能我想要，但手动很难做到。

【参考方案5】：

我认为这两个动作都很好，都不会给我带来任何痛苦，我喜欢关于 noexcept 的意图澄清。

【讨论】：

noexcept 被提议作为一种异常规范和类似于 decltype 的运算符。基本原理可以在open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2983.html 和相关论文中找到。它解决了几个问题，包括通过移动操作提高异常安全性。

不，我的意思是我喜欢这样一个事实，即 noexcept 准确地说明了它的含义，而不必依赖于指定不会引发异常的异常规范。这意味着我们可以说“异常规范 == 错误且已弃用”，而无需说明它们有时如何用于指定不会引发异常。不过感谢您的链接。

【参考方案6】：

任何认为 noexcept 是个好主意的人都需要阅读这个由 3 部分组成的系列。这是第 3 部分，结论：

http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=483

【讨论】：

noexcept 是一个精简的异常规范。如果没有别的，它提供了丢弃整个异常规范废话的能力，同时保留唯一实际证明可能有用的部分。问题不是“我们应该在语言中添加noexcept 吗？”而是“我们可以摆脱多少异常规范？”。

@DavidThornley 异常规范不是很有用，但它们无害。只有围绕这些混淆是有害的，并且更改不太可能消除这种混淆。

【参考方案7】：

我想现在支持它们的任何编译器都将在可预见的未来继续支持它们作为可选扩展，以便人们仍然可以编译他们现有的代码。

【讨论】：

@JB 仅当他们坚持使用该编译器/平台时。

没错，但希望它能给那些受影响最大的人一些时间来更改他们的代码。 throw 应该不需要太多修复，我猜 export 会，但无论如何都没有广泛实施

Herb Sutter 在问题链接的文章中对此进行了详细介绍。如果您的代码使用export，那么它使用的是EDG（唯一的实现），所以无论如何您都不能切换到另一个编译器。将它从标准 (a) 中删除会导致除基于 EDG 的编译器之外的符合标准的编译器，这是有史以来第一次； (b) 允许 EDG 按自己的时间表将其删除。如果仅弃用了异常规范，则所有编译器都必须继续支持它们，因此该问题不适用。

@Steve 你当然可以期待切换到另一个编译器——当我问这个问题时，我对这种事情很感兴趣。

@Neil：是的，但这将是一种非常模糊的期望。你知道还有其他人甚至在export 上工作吗？我有点惊讶 Sutter 没有提到将其作为可选功能（如 int8_t）以及弃用和删除选项的可能性。如果允许 EDG 具有非标准含义 export，那么其他人可能具有 不同 非标准含义，这对我来说似乎比说“如果它做任何事情，它做到了这一点”。但是，由于某些不言而喻的充分理由，可能不需要可选功能。