Arm*_*yan 10 c++ standards-compliance
对于像C++这样的语言,标准的存在是必须的.好的编译器会尽力(最好是大多数好的编译器)来遵守.许多编译器都有语言扩展,其中一些是标准允许的,其中一些不是.后两种例子:
gcc的类型
microsoft的编译器允许纯虚函数声明同时具有纯指定符(= 0)和定义(标准禁止 - 我们不讨论为什么,这是另一个主题:)
(还有很多其他的例子)
这两个示例在以下意义上都很有用:example1是一个非常有用的功能,它将在c ++ 0x中以不同的名称提供.example2也很有用,微软决定不尊重没有意义的禁令.
我很感激编译器提供语言扩展,帮助开发人员完成日常工作.但是这里有一个问题:不应该有一个选项,在设置时,要求编译器尽可能符合标准,无论它们是否与标准一致.例如,visual studio有这样一个选项,称为禁用语言扩展.但是,嘿,他们仍然允许示例2.
我希望每个人都能正确理解我的问题.MSVC允许example2是一件很棒的事情,我非常希望该功能符合标准.它不会破坏任何兼容代码,它没有什么坏处.它只是不标准.
当禁用语言扩展名设置为true时,您希望微软禁用example2吗？请注意,单词microsoft,example2等是占位符:)为什么？
再次,只是为了确保.关键点在于:编译器是否需要提供兼容版本(可选地在设置中设置)(在其限制中,例如我不是在谈论导出),因为它们提供了一个非标准的更好的替代方案,并且是也许甚至是标准的超集,因而没有破坏任何东西.
标准合规性很重要,因为它使代码更易于维护.这表现在很多方面:
从一个版本的编译器移植到另一个版本.我曾经不得不从VC6发布一个120万-LOC应用程序到VC9.VC6因为非常不合规而臭名昭着,即使它是新的.即使在新编译器在最低级别拒绝的最高警告级别上,它也允许不符合规范的代码.如果代码首先以更加合规的方式编写,那么这个项目将不会(不应该)花费3个月的时间.
从一个平台移植到另一个平台.正如您所说,当前的MS编译器具有语言扩展.其中一些是由其他平台上的编译器共享的,有些则不是.即使它们是共享的,行为也可能略有不同.编写符合规范的代码,而不是使用这些扩展代码,使得代码更正确."移植"变得简单地将树拉下来并进行重建,而不是挖掘应用程序的内容,试图找出3位错误的原因.
C++由标准定义.编译器使用的扩展名会改变语言.如果您编写标准C++而不是编译器支持的方言,那些了解C++而不是编译器使用的方言的新程序员将会更快地加速.