对于像 C++ 这样的语言来说，标准的存在是必须的。好的编译器会尽最大努力（至少是大多数好的编译器）来遵守。许多编译器都有语言扩展，其中一些是标准允许的，有些则不允许。后一种例子有2个：
gcc 的 typeof
微软的编译器允许纯虚函数声明同时具有纯说明符（= 0）和定义（这是标准所禁止的 - 让我们不讨论为什么，这是另一个主题:)
（还有很多其他例子）
这两个示例在以下意义上都很有用：example1 是一个非常有用的功能，将在 c++0x 中以不同的名称提供。 example2 也很有用，微软已决定不遵守毫无意义的禁令。
我很感激编译器提供了语言扩展来帮助我们开发人员完成日常工作。但这里有一个问题：难道不应该有一个选项，在设置时要求编译器尽可能符合标准，无论它们是否同意标准。例如，Visual Studio有这样一个选项，称为禁用语言扩展。但是，嘿，他们仍然允许 example2。
我希望大家能够正确理解我的问题。 MSVC 允许 example2 是一件很棒的事情，我非常希望该功能能够出现在标准中。它不会破坏任何兼容的代码，也不会做任何坏事。这只是不标准。
当禁用语言扩展设置为 true 时，您希望 Microsoft 禁用 example2 吗？请注意，microsoft、example2 等词是占位符:)
为什么？
再次强调，只是为了确定一下。关键点是：当编译器提供一个非标准的更好的替代方案时，编译器是否应该为某个功能提供一个兼容的版本（可以在设置中设置）（在其限制内，例如我不是在谈论导出）。甚至可能是标准的超集，因此不会破坏任何东西。
标准合规性很重要，其根本原因是它使您的代码更易于维护。这体现在很多方面：
从编译器的一个版本移植到另一个版本。我曾经不得不发布一个从 VC6 到 VC9 的 120 万个 LOC 应用程序。 VC6 因严重不合规而臭名昭著，即使它是新的。即使在新编译器以最低警告级别拒绝的最高警告级别上，它也允许不合规的代码。如果代码一开始就以更合规的方式编写，那么这个项目就不会（不应该）花了3个月的时间。
从一个平台移植到另一个平台。正如你所说，当前的 MS 编译器具有语言扩展。其中一些由其他平台上的编译器共享，有些则不然。即使它们是共享的，行为也可能略有不同。编写兼容的代码，而不是使用这些扩展，可以使您的代码从一开始就是正确的。 “移植”变得简单地把树拉下来并进行重建，而不是挖掘应用程序的内部试图找出为什么 3 位是错误的。
C++ 由标准定义。编译器使用的扩展改变了语言。如果您使用标准 C++ 而不是您的编译器支持的方言，那么了解 C++ 但不了解您的编译器使用的方言的新上线程序员将更快地掌握速度。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
