为什么没有人用高级功能升级他们的C编译器？

因为新标准的发展需要数年时间.他们正在研究新的C++标准(C++ 0x),以及新的C标准(C1x),但如果你记得每次迭代通常需要5到10年,我不希望看到它在2010年之前左右.

而且,就像在任何民主国家一样,标准中存在妥协.你有强硬派的人说:"如果你想要所有那些花哨的语法糖,那就去购买Java或C#这样的玩具语言,它会带你去买一个棒棒糖",而其他人则说"语言需要更容易,在这些日子里不易出错或者迅速减少开发周期".

双方都是部分正确的,因此标准化是一场漫长的战斗,需要数年时间,并将导致许多妥协.这适用于涉及多个大型聚会的所有事物,它不仅限于C/C++.

因为新标准的发展需要数年时间.他们正在研究新的C++标准(C++ 0x),以及新的C标准(C1x),但如果你记得每次迭代通常需要5到10年,我不希望看到它在2010年之前左右.

而且,就像在任何民主国家一样,标准中存在妥协.你有强硬派的人说:"如果你想要所有那些花哨的语法糖,那就去购买Java或C#这样的玩具语言,它会带你去买一个棒棒糖",而其他人则说"语言需要更容易,在这些日子里不易出错或者迅速减少开发周期".

双方都是部分正确的,因此标准化是一场漫长的战斗,需要数年时间,并将导致许多妥协.这适用于涉及多个大型聚会的所有事物,它不仅限于C/C++.

typedef struct
{
 int i;
 char k;
} elem;

elem user;

会很好地工作.正如其他人所说的那样,它是关于标准的 - 当你在VS2008中实现它时,你不能在GCC中使用它,甚至在GCC中实现它时,你肯定不会编译其他东西.以上方法随处可见.

另一方面 - 当我们有boo类型的C99标准时,for()循环和块中间的声明 - 为什么不是这个特性呢？

首先,编译器需要支持该标准.即使标准在后见之明看起来很尴尬,这也是事实.其次,编译器供应商会添加扩展.例如,许多编译器支持这一点:

(char *) p += 100;

将指针移动100个字节而不是100 p指针的任何类型.严格来说,这是非标准的,因为演员删除了左值p.

非标准扩展的问题在于您不能指望它们.如果您想要切换编译器,使代码可移植或使用第三方工具,那么这是一个大问题.

C在很大程度上是自身成功的牺牲品.使用C的主要原因之一是可移植性.几乎所有硬件平台和操作系统都有C编译器.如果您希望能够在C中编写代码的任何地方运行代码.这会产生巨大的惯性.在不牺牲首先使用该语言的最佳方法之一的情况下,几乎不可能改变任何东西.

软件开发人员的结果是您可能需要写入最小的公分母,通常是ANSI C(C89).例如:运行下一版本Perl的虚拟机Parrot正在用ANSI C编写.Perl6将具有非常强大和富有表现力的语法,并且在语言中融入了一些令人费解的概念.但是,实现是使用几乎完全相反的语言构建的.原因是这将使perl可以在任何地方运行:PC,Mac,Windows,Linux,Unix,VAX,BSD ......

未来的C标准永远不会采用这种"特性" ,原因只有一个:它会严重破坏向后兼容性.在C中,struct标签具有与普通标识符不同的名称空间,这可能会也可能不会被视为特征.因此,这个片段:

struct elem
{
    int foo;
};

int elem;

在C中完全没问题,因为这两个元素位于不同的名称空间中.如果未来的标准允许您声明没有struct限定符或适当的typedef的struct elem,则上述程序将失败,因为elem被用作int的标识符.

事实上,未来的C标准确实打破向后兼容性的一个例子是当C99不允许没有显式返回类型的函数时,即:

foo(void); /* declare a function foo that takes no parameters and returns an int */

这在C99中是非法的.但是,仅仅通过添加int返回类型来使这个C99兼容是微不足道的.如果突然的struct标签没有单独的命名空间,那么"修复"C程序并不是那么简单.

我发现当我实现C和C++的非标准扩展时,即使人们请求它们,它们也不会被使用.C和C++世界绝对围绕严格的标准合规性.许多这些扩展和改进已经在D编程语言中找到了肥沃的土壤.

Walter Bright,数字火星

仍然使用C的大多数人使用它是因为他们要么:

针对非常特定的平台(即嵌入式),因此必须使用该平台供应商提供的编译器

关注可移植性,在这种情况下,非标准编译器会破坏目的

对普通C非常舒服并且没有理由改变,在这种情况下他们只是不想.