理论上，作为原始作者，您可以自由选择和命名标准，然后期望其他人遵循它。在实践中，如果您支持 HPC 系统，那么您的选择可能会受到您用于测试的给定系统的工具堆栈的编译器标准的限制（您正在测试您的软件，不是吗？ ？）。这可能涉及必须滚动您自己的代码来解决各种编译器错误，这些错误已经溜进了野外的各种实现中。这一切都应该记录在案。

就追随人群而言，遵循 clang 的 C11 实现的较新版本现在相对不太可能让潜在用户冷落，但如果有人试图在古怪的硬件上构建，请不要太惊讶从古老版本的 gcc 派生的手动编译器。然后取决于您的项目，您想尝试为他们提供多少免费客户支持。

您绝对应该跳到 C99 或更新版本（！）。C99 标准引入了restrict关键字。粗略地说，使用这个关键字可以通知编译器A[i]并且B[j]不要访问相同的内存位置。在这种情况下，编译器可以生成更好的优化代码。

例如，它使编译器更容易自动矢量化代码。这对于在当今通常支持 SIMD 指令集（例如 Intel SSE / AVX、Arm NEON、PowerPC Altivec 等）的 CPU 上实现高性能至关重要。

引用 restrictWikipedia 页面： 在 C 中使用 restrict 关键字原则上允许非钝角 C 实现与用 Fortran 编写的相同程序相同的性能。

我会说，如果有疑问，请尽可能使用最古老的标准。谁知道我们会在功能越来越强大的物联网和加速器设备上遇到什么样的编译器。自定义安装的并行集群也总是能带来惊喜。

使用限制是有充分理由的，但我会通过使用 cmake 或 autoconf 测试其可用性并以一种可移植的方式执行此操作，如果不支持，#define 将其设置为空。这样，您就可以两全其美。