在gcc中启用C ++ 0x支持的副作用

问题描述

| 通过链接，我想知道在GCC中启用C ++ 0x是否会有一些副作用。 根据gcc的说法：\“ GCC对C ++ 0x的支持是实验性的\”。 我担心的是，例如，编译器生成的代码会有所不同，或者标准库使用的某些C ++ 0x功能在gcc中已损坏。 因此，如果我不明确使用C ++ 0x的任何功能，是否会破坏我现有的代码？     

解决方法

        C ++ 0x支持已经并且正在大力开发中。一方面，这意味着错误会得到快速修复；另一方面，这意味着可能会存在一些小的错误。我之所以这么说，是因为两个原因：

libstdc++

并没有从头开始重写，因此所有旧元素都像stable1ѭ中的任何一个元素之前一样稳定，如果不是更稳定的话，则是由于多年的错误修复。 新旧标准中的一些极端情况尚未解决。您在谈论这些运行时怪癖吗？否。now2ѭ支持现已开发到4个发行版，请放心。 该标志的大部分影响将在新的语言功能中体现出来，移动构造函数和s3ѭ（在posix平台上）之类的库功能不会影响不使用它们的代码。 最重要的是，在日常生产中，实验太严格了。在GCC致力于支持的三四年中，该标准已发生更改。

c++0x

的旧版本将在较新的GCC中被破坏，但这是一件好事。就“非付费pdf世界”而言，“ 2”已完成，因此不应添加任何重大更改。事先确定是否需要新的东西，因为一旦习惯使用它就无法将其关闭。     ,        通常，它不会破坏您的源代码，但是您可能会包含（即使没有注意到它也不知道它）C ++ 0x惯用法，这些惯用法由于启用了这些功能而可以编译，但是不会在严格的C ++编译器中编译（例如，在C ++ 0x中，您可以使用ѭ6作为模板终止符的模板，但在C ++中则不能，因此，如果忘记用空格分隔它，则尝试在C ++中编译此代码时会遇到问题。编译器）。     ,        R值引用/移动是一项功能，会对编译器进行优化等方式产生巨大影响。即使您未在自己的代码中使用move，STD include也将自动切换到包括move ctor / assignment的新版本。 在某些情况下，编译器可以为用户定义的类隐式创建移动构造函数/赋值运算符。这些规则在标准化过程中进行了几次更改（我什至不知道当前的规则是什么）。因此，根据编译器的确切版本，它可能会使用一组规则来生成这些隐式函数，即使在最新版本的标准中也是如此。 其他大多数主要的C ++ 0x更改不会对运行时产生重大影响，它们主要是编译时（constexpr，字符串文字，变量模板）或语法帮助器（foreach，自动，初始化列表）。     ,        我最初写的是您链接的问题，因为（在我看来）这里描述的是一个非常大的问题。基本上，编译器无法识别将

shared_ptr

函数重载为a8ѭ类型。我认为这是一个巨大的缺陷。它已从GCC 4.5修复到GCC 4.6，但它只是一个大错误的示例，例如，仍然存在于ubuntu中GCC的默认安装中。因此，尽管很快修复了错误，但仍有可能存在错误，并且您可能会浪费一个周末寻找这些错误的来源和解决方案。 基于这种个人经验，我的建议是避免使用C ++ 0x，直到从GCC对C ++ 0x的支持描述中删除“ experimental”一词，或者直到您实际上需要任何C + + 0x的功能在某种程度上会导致其他实现方式严重牺牲良好的设计。