使用[[noreturn]]之外的属性的建议？

Question

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

定义的两个属性是[[ noreturn ]]和[[ carries_dependencies ]]。该标准揭示了编译器应如何对未知属性做出反应 - 因此，按照标准，它们可能会因错误消息而停止。这不是例如 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__的数量将始终在增加，并且语言定义一种包含损坏的方法是有意义的。它不需要彻底改变人们编写不可移植代码的方式，也不需要使不可移植代码可移植（尽管标准属性可以这样做）。只需为咖啡因添加的编译器后端工程师提供一个沙箱，就可以在他们想要扩展语法时使用。

但是，有点令人担忧的是，除了当前标准的语言之外，没有为实现或语言保留任何属性标记。因此，当他们决定将更多标准化时，会遇到麻烦。