C99 标准的意义何在？答案

【问题标题】：What is the point of the C99 standard?C99 标准的意义何在？
【发布时间】：2011-05-13 13:38:36
【问题描述】：

C99 为该语言添加了一些有用的特性，但我发现很难推荐任何依赖于 C99 的实践。这样做的原因是因为 C99 语言的实际实现很少（任何？）。当然，少数编译器的支持有限，但没有人愿意花时间编写 C 代码只是为了让它不可移植。

鉴于该标准是在 10 多年前编写并最终确定的，这令人沮丧。另外，我不时听到关于 C1x 的讨论，我想知道为什么有人会采取措施修改该语言，因为该语言的当前版本尚未实现。

所以我的问题是，作为今天的 joe blow C 程序员，什么是有用的 w.r.t. C99 标准对我来说（如果有的话）？

【问题讨论】：

标签： c c99

【解决方案1】：

只要您没有被锁定在不支持 C99 的环境（尤其是嵌入式系统）中，您就应该使用 C99。

是的，如果您知道您的库将被使用 MSVC 的人使用，您就不能在接口中使用 C99 功能，但没有理由在实现中不使用 C99（除了库功能当然是依赖）。

原始答案：“呃？哪些编译器不支持 C99？另外，当您从编译器转向工具时，实际上 C99 比 C89 更受支持。”

【讨论】：

我不知道任何支持 C99 的编译器。 GCC 和 MSVC 都没有，这些是我定期处理的唯一编译器。
@Billy 好吧，如果您认为这种状态不受支持 gcc.gnu.org/c99status.html 那么我想您不能真正编写任何代码 :-) 一旦“支持”标准，它就已经被弃用了。 MSVC居然正式支持C？
根据该页面，它缺少wctype.h 和stdint.h 中大部分有用的内容。我对其他缺失的东西不是 110% 熟悉，但这些都是不存在的重要功能。
我认为您需要支持您的说法，即“C99 实际上比 C89 更受支持。”
@Billy ONeal：我相信 wctype.h 的所有“缺失”是宽字符格式字符串检查，C99 无论如何都没有指定 - 它只是一个“很高兴拥有” . stdint.h 仅在“某些平台”上丢失。

【解决方案2】：

MSVC 不支持，也可能永远不会支持 C99。但微软几乎没有动力更新他们的 C 编译器。他们不会因此失去太多生意。

但是有很多编译器支持 C99。

关于 gcc：

您是对的，也许 C99 对库代码没有用处（并且可能永远不会没有 Microsoft 的支持），但是如果您正在从事可以选择编译器和工具的内部或个人项目，那么便携性不是什么大问题。

【讨论】：

+1 以获得真正回答我的问题而不是与我争论的答案。
@Billy 好吧，没有人在争论 MSVC 不支持 C99 的事实。如果这是您想听到的，您应该重新提出问题。
一旦新的 C++ 标准正式纳入其中的许多功能，MS 将支持 C99 功能。他们不关心 C，但他们不想在 C++ 世界中被抛在后面。
@R，MSVC 在编译 C 代码时是否支持混合声明和代码？尽管它在 C++ 中是允许的，但它并不是我最后一次使用它（已经有一段时间了）。我更大的问题是：微软是否真的声称他们会向 C 编译器添加重叠功能，还是只是假设？
@Billy 只要您没有被锁定在不支持 C99 的环境（尤其是嵌入式系统）中，就应该使用 C99。是的，如果您知道您的库将被使用 MSVC 的人使用，您就不能在接口中使用 C99 功能，但没有理由在实现中不使用 C99（当然除了库功能依赖)。

【解决方案3】：

关于 C1x，我认为值得注意的是，标准委员会很清楚 C99 并未被广泛采用，并且不想重复同样的错误（或使情况变得更糟）。来自C1x charter：

与 C9X 不同，伦敦会议上的共识是不应该发明，无一例外。只有那些有历史和共同点的特征应考虑由商业实施使用。还有一定要注意以使标准和商业化的方式标准化这些功能实现兼容。

还有：

原始标准受到用户和供应商的好评社区。但是，C99 并没有得到广泛的认可。

【讨论】：

当他们考虑采用所有那些为了破坏 C 和可移植性而创建的无用的 MS 功能时，我发现很难认真对待这些陈述——其他人都不想支持的功能。
@R..：如果您指的是字符串函数的各种“安全”版本，我认为它们是一件好事。（或者他们可以选择使用strlcpy 和strlcat；我不在乎。）根据定义，发明任何扩展都会“破坏可移植性”，但是将其合并到标准中的目的是解决这个问题。此外，如果这意味着微软可能真的想加入 C1x，那就太好了。
恕我直言，与其说“没有发明”，更好的方法是指定可以通过宏在现有编译器上模拟的功能，但在新编译器的支持下可以更好地工作（例如标准定义诸如“向右旋转”和“向左旋转”之类的宏，可以通过调用（希望）内联函数来模拟，但也可以扩展到编译器内在函数。如果 x 和 y 是“简单变量” ，(x>>y) | (x >> (31-y) >> 1) 可能会转换为令人讨厌的指令序列，__rotright(x,y) 更有可能产生单个指令。

【解决方案4】：

FreeBSD 现在使用 Clang 进行内核编译，它几乎支持 C99。

【讨论】：

【解决方案5】：

C99 带来了真正使 C 编程更容易和更安全的功能：

语言也更具表现力

在我的 linux 机器上，我有四个编译器支持 C99 到令人满意的程度，这使得它可以在日常基础上使用：gcc、clang、opencc 和 icc。

前两个是开源编译器，clang 试图使代码与 gcc 兼容（意味着 C99 支持大致相同）。

后两个来自两个主要的 CPU 生产商，是商业的，但对非商业用户有慷慨的许可政策。他们的 C99 有点少，尤其是他们对inline 的支持似乎还没有完全符合标准。

【讨论】：

想链接到 opencc 的规范网站吗？
如果icc的Windows版本支持C99吗？
@Billy，我不使用 Windows，所以我不确定。但如果它不这样做，那将是令人惊讶的，至少对于语言本身而言。不过，C 库支持可能会有所不同。
自动存储持续时间的复合文字左值是否使语言更安全、更具表现力？复合文字右值是一个很好的补充，静态持续时间的常量复合文字会很好，但复合文字左值无法控制的短暂生命周期使它们看起来比手动创建的变量更不安全。
@supercat，复合文字至少具有在表达式之前声明的变量的生命周期。这与绑定到表达式的 C++ 的临时变量不同。它们被绑定到范围，就像其他对象一样。

【解决方案6】：

如果您关心性能，那么restrict 是没有办法的。

【讨论】：