为什么新的 C 书籍不遵循 C99 标准？
我见过的几乎所有（相对）关于 C 编程的新书似乎都不遵守 C99 标准，或者在额外的章节中对其进行了介绍。来自 Java 背景的 C99 标准使我的迁移（嗯，仍在迁移 ^^）变得更加容易，这可能也适用于其他语言。
大多数 C 开发人员似乎还没有接触到 C99。但为什么？
Nearly every (relatively) new book about c programming I've seen doesn't seem to adhere to the C99 standard, or they cover it in an extra chapter. Comming from a Java background, the C99 standard made the migration (well, still migrating ^^) much easier for me, and this probably applies to other languages, too.
It seems like C99 hasn't reached most of the C developers yet. But why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
简短回答：编译器支持的安装速度很慢，而且 C 程序员是一群保守的人，他们改变自己的行为很慢。
Short answer: compiler support is slow to get installed and c programmers are a conservative lot who change their behavior slowly.
我强烈怀疑这主要是因为 MSVC 没有尝试支持 C99，而且很可能永远不会。同一条船上有一些嵌入式编译器，但它们的通用性不足以单独发挥重要作用。 AFAIK 其他人至少都在尝试尽可能多地实现 C99。
在实践中没有太多理由不使用 C99 的选定功能，但如果您要学习并编写一个 C 标准，而且只有一个，那么它必须是 C89。
此外，编写介绍性 C 文本可能相当困难且令人困惑，该文本一开始就说“好吧，有两种不同的标准，我将使用三种不同颜色的文本：一种用于 C89，一种用于 C99，一种用于 C89”。一举两得”。写一整本书关于 C99，然后“收回”你在附录中所说的关于 C89 的很多内容可能比写关于 C89 然后添加到关于 C99 的附录中更困难。
不过，所有的猜测。实际上，您必须询问您正在阅读的书籍的作者（或者在某些情况下可能违背您所有的编程本能，并且阅读前言;-)）
I strongly suspect it's mainly because MSVC does not attempt to support C99, and quite likely never will. There are a few embedded compilers in the same boat, but they're hardly common enough to matter much individually. AFAIK everyone else is at least trying to implement C99 as much as possible.
There isn't much reason in practice not to use selected features of C99, but if you're going to learn and write to one C standard, and only one, then it must be C89.
Furthermore, it's probably quite difficult and confusing to write an introductory C text which starts out by saying "OK, there are two different standards, and I'm going to use three different colours of text: one for C89, one for C99, and one for both". It's also probably harder to write about C99 for a whole book, and then "take back" a lot of what you've said in an appendix about C89, than it is to write about C89 and then add to it in an appendix about C99.
All speculation, though. Really you'd have to ask the authors of the books you're reading (or perhaps in some cases go against all your programming instincts, and read the foreword ;-))
在现有代码库上切换到新编译器的风险通常是未知的，但这可能会非常痛苦，最明智的做法是只有当您有几个月的时间来消除任何错误/更改时才进行切换。对于非常旧的代码库，有时最明智的做法是根本不进行切换。
我敢打赌，大多数使用 C 的项目根本不愿意切换到 C99，因为现有的大型代码库几乎没有任何好处，并且有相当多的潜在缺点。我在一家大型软件公司工作，该公司将编译器与代码一起检查到源代码树中，并且永远不会切换产品的编译器。
The risk of switching to a new compiler on an existing code base is generally unknown, but it can be quite painful, its wisest to only switch when you have months of time to shake out any bugs/changes. And for really old code bases, sometimes It's wisest to just never switch at all.
I'd be willing to bet that the majority of projects that use C aren't willing to switch to C99 at all since there's hardly any upside for a large existing code base and quite a bit of potential downside. I worked at one large software house that checked the compilers into th source tree right along side the code and would never switch compilers for a product.