5

我看过的几乎每本（相对）关于 c 编程的新书似乎都不符合 C99 标准，或者他们在额外的章节中介绍了它。来自 Java 背景，C99 标准使迁移（嗯，仍在迁移 ^^）对我来说更容易，这可能也适用于其他语言。

似乎 C99 还没有接触到大多数 C 开发人员。但为什么？

4

3 回答 3

13

简短的回答：编译器支持的安装速度很慢，c 程序员是一个保守的人，他们的行为改变得很慢。

于 2010-02-20T20:04:09.693 回答
11

我强烈怀疑这主要是因为 MSVC 不尝试支持 C99，而且很可能永远不会。同一条船上有一些嵌入式编译器，但它们几乎没有足够的普遍性，以至于单独影响很大。AFAIK 其他所有人至少都在尝试尽可能多地实施 C99。

在实践中没有太多理由不使用 C99 的选定特性，但如果你要学习和编写一个 C 标准，而且只有一个，那么它必须是 C89。

此外，编写介绍性 C 文本可能非常困难和令人困惑，它的开头是“好的，有两种不同的标准，我将使用三种不同颜色的文本：一种用于 C89，一种用于 C99，以及一个为两个”。写一整本书关于 C99，然后“收回”你在关于 C89 的附录中所说的很多内容，也可能比写关于 C89 的内容然后在关于 C99 的附录中添加它更难.

不过都是猜测。真的，您必须询问您正在阅读的书籍的作者（或者在某些情况下可能违背您所有的编程本能，并阅读前言;-)）

于 2010-02-20T23:30:37.783 回答
3

在现有代码库上切换到新编译器的风险通常是未知的，但它可能会非常痛苦，只有当您有几个月的时间来消除任何错误/更改时才切换是最明智的。对于非常老的代码库，有时最明智的做法是根本不切换。

我敢打赌，大多数使用 C 的项目根本不愿意切换到 C99，因为现有的大型代码库几乎没有任何好处，而且还有相当多的潜在缺点。我在一家大型软件公司工作，该公司将编译器检查到代码旁边的源代码树中，并且永远不会为产品切换编译器。

于 2010-02-20T20:30:31.727 回答