c++11 - 关于使用 [[noreturn]] 之外的属性的建议？

Question

来自另一个 question 中关于使用供应商特定属性的讨论我问自己， “对于使用标准中未列出的属性，我们应该告诉人们什么规则” ?

定义的两个属性是 [[ noreturn ]]和 [[ carries_dependencies ]] .该标准对编译器应如何对未知属性使用react保持开放——因此，根据标准，它们可能会因错误消息而停止。这不是什么，例如GCC 会，它发出警告并继续。这可能是最常见的编译器所期望的行为。出于这个原因，我想阅读标准中的“应该”，但我们没有。

N2553论文提出了灵活的属性。它列出了 GCC 使用的更多属性(unused , weak ) 和 MSVC ( dllimport )。对于广泛支持的并行化框架 OpenMP，建议使用范围属性，例如。 omp::for(clause, clause) , omp::parallel(clause,clause) .因此，我们很可能会在它们完全支持语法后很快看到一些供应商特定的属性。

因此，当我们现在“走出去”向人们介绍 C++11 时，关于使用属性的建议应该是什么？

仅使用 noreturn和 carries_dependencies

改用您的编译器旧语法，例如。 __attribute__((noreturn))并在移植代码时定义一个宏(当前情况)

自由使用您最喜欢的编译器支持的那些属性，知道此代码可能无法移植到另一个符合标准的编译器，因为如果标准允许编译器因错误而停止，您必须考虑这会发生。这听起来有点像提倡编写不可移植的代码。

或者，我的猜测是，希望最常用的编译器对未知属性发出警告，因此您可以使用特定于供应商的属性，请记住，在极少数情况下您可能会遇到问题。

请注意最后两个项目符号中的细微差别。虽然两者都说“使用您需要的那些属性”，但 item3 的消息是“不关心其他编译器”，而 item4 隐式地将标准文本“实现定义的行为”改写为“编译器应该发出诊断消息”。

对即将到来的最佳实践有什么建议？

Answer 1

最佳实践——唯一在实践中具有合理可移植性的实践，更不用说标准中的歧义——是使用宏。我们还需要很多年才能忘记不支持属性的编译器。

编译器数量和自定义数量__keywords__由这些编译器定义的总是会增加，并且语言定义一种方法来控制损害是有意义的。它不需要彻底改变人们编写不可移植代码的方式，或者使不可移植代码具有可移植性(尽管标准属性可以做到这一点)。当他们想要扩展语法时，为咖啡因缠身的编译器后端工程师提供一个沙箱是有好处的。

然而，有点令人担忧的是，除了当前标准的那些之外，没有为实现或语言保留任何属性标记。因此，当他们决定对更多内容进行标准化时，就会遇到麻烦。