新的C项目何时应针对非常老的C标准（> 20年，即C89）？

偶尔我会看到针对较旧的C标准（通常是C89）的大型，相对较新的开源C项目。有一个例子。这些项目由聪明的人掌舵，因此他们可能对这个我不知道的决定有很好的理由。除了疑问的好处之外，似乎基本原理是“较老和标准化总是更具可移植性和更好性”，这是荒谬的，因为逻辑结论是FORTRAN优于C，COBOL甚至比FORTRAN更好。

什么时候以及为什么有理由要求新的C项目针对非常老的C标准？

我无法想象用户系统绝对不能更新其C编译器而可以自由安装新软件的情况。例如，Debian的LTS版本具有gcc 4.6软件包，该软件包支持C99和某些C11。我猜想肯定会存在奇怪的情况，而像systemd这样的程序正是针对这些用户的。

我能想到的最合理的用例是，预期用户将具有异国情调的体系结构，在该体系结构上只有 C89编译器可用，但他们完全愿意安装新软件。鉴于指令集体系结构多样性的下降，这似乎是一个过度假设的场景，但我不确定。

……“可笑，老套”

该陈述变得更好时变得荒谬，这完全是主观的。您没有为项目选择语言和标准，因为上次聚会中一半的人正在使用它。之所以选择它，是因为您已经研究并了解了您要解决的问题，并确定这是完成该任务的正确工具。

对于一般的标准，某些项目需要考虑可移植性，这就是选择较旧的项目可以带来一些好处的地方。当您将库作为产品开发时，尤其如此，这是达到他人目的的一种手段。您想要做的最后一件事是写一些您无法出售的东西，因为它需要您尚未遇到的客户可能没有的编译器。菲利普·肯德尔（Philip Kendall）对嵌入式世界的评论不胜枚举。发生了很多事情，要么是因为人们仍然必须为旧的，稳定的平台编写新代码，要么是那些无法从额外功能中受益且无法获得最新编译器的平台。当您完全控制项目的各个方面时，

具体来说，对于C来说，存在一个问题，就是您要获得最新标准的回报。从K＆R到C89的过渡是一个巨大的变化，需要花费很多精力来清理旧代码，但最终还是做了很多事情。C99和C11的变化相比较而言，它是次要的，并且大多数最近开发的CI遇到仍会通过C89，因为它不使用新功能。很难说强制C99优于C89是正确的选择，因为它支持单行注释，具有本机布尔数据类型并且可以执行可变长度数组。注释和布尔值具有难看的解决方法，可以用其他效率稍低的方式来处理VLA。C11将VLA降级为可选，如果它们在您的实现中占主导地位，那可能是选择较旧的C99的理由。

当跨多种平台的可移植性很重要时。这可能包括过时的平台，以及许多嵌入式处理器，这些处理器仅具有最低限度的编译器。

从某种意义上说，C89是“最低公分母”。它是第一个经过适当标准化的版本，几乎可以认为当今使用的所有编译器都可以实现C89的某些超集。

还有一个问题是，尽管Microsoft Visual C ++相对较好地符合C ++标准，但是在C模式下却长期停留在C89上。因此，任何未使用最新Visual Studio的人都可能限于C89。

我必须承认，主要由于Microsoft，我仍然编写伪C89代码（不完全符合C99）。我在Windows方面非常依赖MSVC，但它们仍然不完全符合C99，而是将大部分精力放在C ++ 17及更高版本上。

最重要的是，我正在开发C SDK，许多插件开发人员都在其中使用MSVC进行插件开发，还有一些仍使用MSVC2010。因此，仍然有流行的编译器在不那么奇特的平台上广泛使用（除非您考虑Windows异国）甚至还没有完全实现C99。当您希望与最大范围的编译器具有广泛的兼容性（这是SDK是用C而不是C ++编写的主要原因之一）时，仍然有许多被广泛使用（至少是MSVC），这在当时是落后的关于C支持。自C99以来已经过去了二十年，而且我们仍然没有VLA，例如，在MSVC AFAIK中（尚未检查MSVC 2017，但考虑到Microsoft对C的立场，我怀疑它是否更符合C99） 。

因此，不幸的是，仍然有一些新的编译器，它们实际上非常好，并且还具有良好的优化器和调试器，它们甚至还不完全符合C99。当然，如果不是因为这个原因，我会跳过C11。

除了与插件和MSVC的源兼容性外，还可以与其他语言互操作。其他一些语言通过FFI使用SDK，其中一些FFI仅了解C89。从dylib导入函数时，他们可能不理解bool或仅_Bool作为一个简单示例，而仅理解int。

是的，赞成的观点是可移植性，但是问题是，是否实际上有非假设的系统只能使用C89编译器，但正在编译新的软件发行版。即，如果我正在开始一个新的C项目，我如何确定坚持使用C89是否可以增加潜在用户的数量？

只是注意到了这一点，但在某种程度上是呼应Blrfl，在我看来，使用C99和C11所带来的生产率提升并不是那么巨大，而失去允许人们使用MSVC编写插件的能力可能会是一笔巨大的成本（尤其是因为我使用的产品到目前为止，Windows上的Windows XP拥有最大的市场份额，普通用户经常购买和下载许多第三方插件。我从事的产品类型几乎介于程序员/脚本开发环境和艺术家的用户端产品之间，因为许多人都希望在其基础上开发新产品，以提供新功能并实现特殊功能。善良的人们还没有看到。因此，就我而言，至少对于SDK而言，支持C89实际上是一个非常简单的决定。

我想您必须对周围的编译器有所了解，并尝试找出目标人群。如果您不是要为Windows开发插件体系结构，也不是进行任何嵌入式编程，也不是尝试构建可被最广泛的编译器和语言使用的软件开发工具包，那么对于C99 +而言，它无疑将使事情变得更加容易。远。也可以考虑从C99开始获得多少生产力提升。我从VLA之类的应用程序中受益匪浅，因为我依靠足够简单的方法在数据适合时使用堆栈，否则就进行堆放。

但是，从诸如MSVC之类的流行编译器到其他语言的FFI，还有很多事情是落后的，这很酷，因为它们可以直接从dylib导入和调用C函数，但在功能上也可能有些落后次。因此，根据您的领域，还有很多实际的业务要考虑的事项，而不是仅仅出于某种美感而偏爱老式的和标准化的。