C99标准的意义是什么?

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

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

http://en.wikipedia.org/wiki/C99#Implementations

关于合同通用条款:

http://gcc.gnu.org/c99status.html

你说得对,也许C99对库代码没有用处(而且可能永远都离不开微软的支持),但是如果你在一个内部或个人项目中工作,你可以选择编译器和工具,那么可移植性就不是什么大问题了。

C99带来了一些特性,这些特性使得用C语言编程更容易,也更安全:

• 指定的初始值设定项
• 复合文字
• for -范围变量
• 固定宽度整数类型

这种语言也更具表现力

• 可变参数宏
• inline 功能

在我的linux机器上,我有四个编译器,它们支持C99,使之可以在日常使用: gcc , clang , opencc 和 icc .

前两个是开源编译器,clang试图与gcc代码兼容(这意味着C99支持基本相同)。

后两个是来自两个主要的CPU生产商,是商业的,但有慷慨的非商业用户的许可政策。他们的C99有点少,特别是他们支持 内联 似乎还不完全符合标准。

关于C1x,我认为值得注意的是,标准委员会很清楚C99没有被广泛采用,不想重复同样的错误(或使情况更糟)。从 C1x charter :

与C9X不同,伦敦会议的共识是 发明,无一例外。只有那些有历史和共同点的特征 应考虑由商业实现使用。也必须注意 以使标准和商业 实现兼容。

以及:

最初的标准得到了用户和供应商的积极响应 社区。然而,C99并没有得到如此广泛的接受。

当您没有被锁定在不支持C99的环境中时,您应该使用C99(最明显的是嵌入式系统)。

是的,如果你知道你的库将被使用MSVC的人使用,你不能在接口中使用C99特性,但是没有理由不在实现中使用C99(当然除了库特性依赖)。

最初的回答是:“嗯?哪些编译器不支持C99?另外,当您从编译器转移到工具时,C99实际上比C89更受支持。”

如果你喜欢表演,那就没办法了 restrict .

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