C99标准的意义何在?

发布于 2024-10-04 01:03:38 字数 255 浏览 5 评论 0原文

C99 为该语言添加了一些有用的功能,但我发现很难推荐任何依赖于 C99 的实践。原因是 C99 语言的实际实现很少(有吗?)。当然,少数编译器的支持有限,但没有人愿意花时间编写 C 代码,却发现它不可移植。

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

所以我的问题是,作为当今的 C 程序员,C99 标准对我来说有什么用处(如果有的话)?

C99 adds several useful features to the language, yet I find it difficult to recommend any practice which depends upon C99. The reason for this is because there are few (any?) actual implementations of the C99 language. Sure, there is limited support in a few compilers, but nobody wants spend the time to write C code only to have it be unportable.

This is frustrating given that the standard was written and finalized over 10 years ago now. Plus I hear discussions of a C1x from time to time, and I wonder why someone would be taking steps to revise the language given that the current version of the language isn't yet implemented.

So my question is, as joe blow C programmer today, what is useful w.r.t. the C99 standard to me (if any)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

注定孤独终老 2024-10-11 01:03:38

C99 带来的功能确实使 C 编程更容易、更安全:

  • 指定初始化器
  • 复合文字
  • for范围变量
  • 固定宽度整数类型

内联更具表现力

  • 该语言还通过可变参数宏
  • code> 函数

在我的 Linux 机器上,我有四个编译器,它们对 C99 的支持达到了令人满意的程度,使其可以在日常使用中使用: gcc clangopencc

前两个是开源编译器,其中 clang 尝试与 gcc 代码兼容(意味着 C99 支持大致相同)。

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

C99 brings features that really makes programming in C easier and more error safe:

  • designated initializers
  • compound literals
  • for-scope variables
  • fixed width integer types

The language is also much more expressive with

  • variadic macros
  • inline functions

On my linux machine I have four compilers that support C99 to a satisfying extent that make this usable on a daily base: gcc, clang, opencc and icc.

The first two are open source compilers where clang trying to be code compatible to gcc (meaning C99 support is about the same).

The later two are from the two major CPU producers and are commercial but with generous license policy for non commercial users. Their C99 is a bit less, in particular their support for inline seems not completely consistent with the standard, yet.

思慕 2024-10-11 01:03:38

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

但有很多编译器支持 C99。

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

关于 gcc:

< a href="http://gcc.gnu.org/c99status.html" rel="noreferrer">http://gcc.gnu.org/c99status.html

你是对的,也许 C99 没有用对于库代码(并且可能永远不会没有 Microsoft 的支持),但如果您正在开发一个内部或个人项目,您可以选择编译器和工具,那么可移植性就不是什么大问题。

MSVC does not, nor will it probably ever, support C99. But Microsoft has little incentive to update their C compiler. It's not like they will lose much business over it.

But there are plenty of compilers that have support for C99.

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

Regarding gcc:

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

You are right that perhaps C99 is not useful for library code (and may never be without Microsoft's support), but if you're working on an in-house or personal project where you can pick the compilers and tools, then the portability is not much of an issue.

临风闻羌笛 2024-10-11 01:03:38

关于C1x,我认为值得注意的是,标准委员会很清楚C99还没有被广泛采用,并且不想重复同样的错误(或者让情况变得更糟)。来自 C1x 章程

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

和:

原始标准得到了用户和供应商的非常积极的欢迎
社区。然而,C99 并没有受到如此广泛的欢迎。

Regarding C1x, I think it's worth noting that the standards committee is well aware that C99 has not been widely adopted and doesn't want to repeat the same mistakes (or to make the situation worse). From the C1x charter:

Unlike for C9X, the consensus at the London meeting was that there should be no
invention, without exception. Only those features that have a history and are in common
use by a commercial implementation should be considered. Also there must be care to
standardize these features in a way that would make the Standard and the commercial
implementation compatible.

And:

The original standard had a very positive reception from both the user and vendor
communities. However, C99 has been not so widely received.

芯好空 2024-10-11 01:03:38

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

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

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

You should use C99 whenever you are not locked in an environment that doesn't support C99 (embeded systems most notably).

And yes, if you know that your library will be used by people that are using MSVC, you can't use C99 features in the interfaces, but there is no reason not to use C99 in the implementation (apart from library feature dependencies of course).

Original answer: "Uh? What compilers don't support C99? Plus when you move from compilers to tools, C99 is actually more commonly supported then C89."

好久不见√ 2024-10-11 01:03:38

如果您关心性能,就没有办法绕过限制

If you care for performance, there's no way around restrict.

一场春暖 2024-10-11 01:03:38

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

FreeBSD is now using Clang for kernel compiles and that pretty much supports C99.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文