遵守标准有多重要？

Question

对于像 C++ 这样的语言来说，标准的存在是必须的。好的编译器会尽最大努力（至少是大多数好的编译器）来遵守。许多编译器都有语言扩展，其中一些是标准允许的，有些则不允许。后一种例子有 2 个：

1. gcc 的 typeof

2. 微软的编译器允许纯虚函数声明同时具有纯说明符 (=0) 和定义（标准禁止这样做） - 我们不讨论为什么，那是另一个话题了:)

（还有许多其他示例）

这两个示例在以下意义上都很有用：example1 是一个非常有用的功能，它将在 c++0x 中以不同的名称提供。 example2 也很有用，微软已决定不遵守毫无意义的禁令。

我很感激编译器提供了语言扩展来帮助我们开发人员完成日常工作。但这里有一个问题：难道不应该有一个选项，在设置时要求编译器尽可能符合标准，无论它们是否同意标准。例如，Visual Studio有这样一个选项，称为禁用语言扩展。但是，嘿，他们仍然允许 example2。

我希望大家能够正确理解我的问题。 MSVC 允许 example2 是一件很棒的事情，我非常希望该功能能够出现在标准中。它不会破坏任何兼容的代码，也不会做任何坏事。这只是不标准。

当禁用语言扩展设置为 true 时，您希望 Microsoft 禁用 example2 吗？请注意，microsoft、example2 等词是占位符:) 为什么？

再次强调，只是为了确定一下。关键点是：当编译器提供一个非标准的更好的替代方案时，编译器是否应该为某个功能提供一个兼容的版本（可以在设置中设置）（在其限制内，例如我不是在谈论导出）。甚至可能是标准的超集，因此不会破坏任何东西。

Answer 1

标准合规性很重要，其根本原因是它使您的代码更易于维护。这体现在多种方面：

• 从一个版本的编译器移植到另一个版本。我曾经不得不发布一个从 VC6 到 VC9 的 120 万个 LOC 应用程序。 VC6 因严重不合规而臭名昭著，即使它是新的。即使在新编译器以最低警告级别拒绝的最高警告级别上，它也允许不合规的代码。如果代码一开始就以更合规的方式编写，那么这个项目就不会（不应该）花费 3 个月的时间。

• 从一个平台移植到另一个平台。正如你所说，当前的 MS 编译器具有语言扩展。其中一些由其他平台上的编译器共享，有些则不然。即使它们是共享的，行为也可能略有不同。编写兼容的代码，而不是使用这些扩展，可以使您的代码从一开始就是正确的。 “移植”变得简单地把树拉下来并进行重建，而不是挖掘应用程序的内部试图找出为什么 3 位是错误的。

• C++ 由标准定义。编译器使用的扩展改变了语言。如果您使用标准 C++ 而不是您的编译器支持的方言，那么了解 C++ 但不了解您的编译器使用的方言的新上线程序员将更快地掌握速度。

Answer 2

首先回复几条评论。有问题的 MS VC 扩展是这样的：

struct extension { 
    virtual void func() = 0  { /* function body here */ }
};

该标准允许您实现纯虚函数，但不能像这样“就地”，所以您必须这样写：

struct standard { 
    virtual void func() = 0;
};

void standard::func() { ; }

至于原来的问题，是的，我认为编译器拥有一种尽可能准确地遵循（并强制执行）标准的模式是一个好主意。虽然大多数编译器都有这样的功能，但结果不一定如您/我所希望的那样准确地表示标准。

至少在我看来，这个问题的唯一答案是对于那些关心可移植性的人来说，定期拥有（和使用）至少几个编译器。对于C++，其中之一应该基于EDG前端；我相信它比大多数其他产品具有更好的一致性。如果您定期使用英特尔的编译器，那就没问题。否则，我建议您获取一份 Comeau C++；它只要 50 美元，而且是最接近“参考”的东西。您还可以在线使用 Comeau，但如果您经常使用它，那么值得您自己购买一份。

听起来不像是 EDG 或 Comeau 的托儿之类的东西，但即使您不太关心可移植性，我还是建议您获取一份副本 - 它通常会产生出色的错误消息。多年来，它干净、清晰的错误消息（全部由其本身）节省了足够的时间，足以为编译器支付数倍的费用。

编辑：再看一遍，有些建议看起来相当过时，尤其是对 EDG/Comeau 的建议。自从我最初写这篇文章以来的三年里，Clang 已经从纯粹的实验发展到对于生产使用相当合理。同样，gcc 维护者（IMO）在一致性方面也取得了长足的进步。

与此同时，Comeau 尚未发布其编译器的任何新版本，并且发布了 C++ 标准的新版本。结果，Comeau 现在相对于当前标准来说已经相当过时了（而且情况似乎变得更糟，而不是更好——委员会已经批准了一项新标准的委员会草案，该草案很可能成为 C+） +14）。

因此，尽管我当时推荐了科莫，但今天我（充其量）很难这样做。幸运的是，它提供的大部分优点现在都可以在更主流的编译器中使用——如上所述，Clang 和 gcc 都（显着地）改进了合规性，并且它们的错误消息也得到了显着改进（Clang 已几乎从一开始就非常重视更好的错误消息）。

底线：我仍然建议至少安装两个可用的编译器，但今天我可能会选择与最初编写此答案时不同的编译器。

Answer 3

从长远来看，“不破坏任何东西”是一种滑坡，最好完全避免它。我公司的主要产品比几代编译器（首次于 1991 年使用 RW 编写）的寿命更长，每当需要迁移到较新的开发系统时，都要花费大量精力来梳理编译器扩展和安静的标准违规行为。

但只要有一个选项可以关闭或至少警告“非标准扩展”，我就可以接受。
34、70、6。

Answer 4

我当然想要一个禁用语言扩展的选项来禁用所有语言扩展。为什么？

• 所有选项都应该按照他们所说的去做。
• 有些人需要开发可移植代码，需要一个仅接受该语言的标准形式的编译器。

“更好”是一个主观词。语言扩展对于某些开发人员来说很有用，但对于其他开发人员来说却变得更加困难。

Answer 5

我认为，如果编译器想成为开发时使用的主要模式，那么提供纯标准模式至关重要。当然，所有编译器都应该编译符合标准的代码，但如果它们不认为自己是主编译器，那么它们不扩展并不重要——例如，交叉编译器或较少的编译器流行的平台几乎总是被移植到，而不是有针对性的。

扩展对于任何编译器来说都很好，但是如果我需要的话必须打开它们，那就太好了。默认情况下，我更喜欢仅标准的编译器。

因此，鉴于此，我希望 MSVC 默认情况下仅是标准。与 gcc++ 相同。

统计数据：40、90、15

Answer 6

我认为遵守标准非常重要。

我始终认为源代码更适合人类读者而不是机器。因此，为了向读者传达程序员的意图，遵守标准就像说一种最小公分母的语言。

无论是在家里还是在工作中，我都使用 g++，并且我使用以下标志为其别名，以严格遵守标准。

-Wall -Wextra -ansi -pedantic -std=c++98

查看此页面严格 ANSI/ISO

我不是标准专家，但这对我很有帮助。我编写了 STL 风格的容器库，它们可以在不同的平台上按原样运行，例如 32 位 linux、64 位 linux、32 位 Solaris 和 32 位嵌入式 OSE。

Answer 7

考虑汽车上的指示灯（在某些司法管辖区称为“转向灯”）；它们是一种可靠的方法，可以确定某人要关闭环岛的方向......直到只有一个人根本不使用它们。然后整个系统崩溃了。

当 IE 允许将 document.someId 用作 document.getElementById('someId')....然而，它确实催生了整整一代的程序员，甚至书籍，因此认为它是好的和正确的，因为“它有效”。然后，突然间，所生成的一千万个网站完全不可移植。

标准对于互操作性很重要，如果您不遵循它们，那么拥有它们就毫无意义。

标准合规者可能会因“迂腐”而受到憎恨，但实际上，除非每个人都效仿，否则您将永远遇到可移植性和兼容性问题。

Answer 8

标准合规性的重要性取决于您想要实现的目标。

如果您正在编写一个永远不会移植到当前环境之外的程序（特别是您不打算长期开发/支持的程序），那么它并不是很重要。无论什么有效，都有效。

如果您需要您的程序长期保持相关性，并且可以轻松移植到不同的环境，那么您会希望它符合标准，因为这是（或多或少）保证它在任何地方都能工作的唯一方法。

当然，诀窍在于弄清楚您实际上处于哪种情况。在开始一个程序时，认为它是一个短期黑客，然后发现它非常有用，以至于您仍然在开发/维护它多年，这是很常见的之后。在这种情况下，如果您在程序生命周期之初没有做出任何短视的设计决策，那么您的生活将不会那么不愉快。