关注link，我想知道在GCC中启用C ++ 0x是否有一些副作用。
根据gcc：“GCC对C ++ 0x的支持是 experimental ”。
我害怕的是，例如编译器将生成一些不同的代码，或者标准库使用一些在gcc中被破坏的C ++ 0x特性。
因此，如果我没有明确使用任何C ++ 0x功能，它可能会破坏我现有的代码吗？
答案 0 :(得分：3)
C ++ 0x支持已经并且正在大量开发中。这意味着一件事就是错误很快得到修复，另一件事意味着可能存在小错误。我说小，因为两个原因：
libstdc++尚未从头开始重写，因此所有旧元素都可以像之前c++0x中任何一个一样稳定，如果不是更稳定，因为有几个多年的错误修复。
新/旧标准中的角落案例尚未解决。这些是你谈到的运行时怪癖吗？目前正在为4个版本开发C++0x支持。不用担心。
来自该标志的大部分影响将在新的语言功能中体现出来，移动构造函数和std::thread（在posix平台上）等库函数不会影响不使用的代码它们。
底线，实验性在日常生产中过于严格。标准在三四年内发生了变化，GCC一直致力于支持。 c++0x的旧修订版将在较新的海湾合作委员会中被打破，但这是一件好事。就非付费的pdf世界而言，C++0x已完成，因此不应添加任何重大更改。决定你是否想要新的东西，因为一旦你习惯了它，你将无法将其关闭。
答案 1 :(得分：1)
通常，它不会破坏你的源代码，但你可以包括（即使没有注意到或知道它）C ++ 0x惯用法，因为启用了这些功能而将编译，但不会在严格的C ++中编译编译器（例如，在C ++ 0x中，您可以使用>>作为模板终止符的模板，但不能在C ++中使用，所以如果您忘记用空格分隔它，那么当您尝试编译时会遇到问题这段代码在C ++编译器中。）
答案 2 :(得分：1)
R-Value references/moves是一个可以对编译器如何进行优化等产生巨大影响的功能。即使您不在自己的代码中使用move，STD include也会自动切换到包含move ctors / assignment的新版本。
在某些情况下，编译器可以隐式为用户定义的类创建移动构造函数/赋值运算符。在标准化过程中，这些规则改变了几次（我甚至不知道当前的规则是什么）。因此，根据编译器的确切版本，可能会使用一组规则来生成这些隐式函数，这些函数甚至不在最新版本的标准中。
大多数其他主要的C ++ 0x更改都没有大的运行时影响，它们主要是编译时间（constexpr，字符串文字，varadic模板）或语法帮助程序（foreach，auto，initializer list）。 / p>
答案 3 :(得分：1)
我最初写的是你链接的问题，因为（在我看来）是here所描述的一个非常大的问题。基本上，编译器无法识别将shared_ptr的函数重载到const类型。在我看来，这是一个巨大的缺陷。它已经从GCC 4.5修复到GCC 4.6，但它可以作为一个例子，例如在ubuntu中默认安装GCC时仍然存在的大错误。因此，虽然错误很快得到修复，但仍然可能存在错误，您可能会浪费一个周末来寻找这些错误的来源和解决方案。
基于这种个人经验，我的建议是避免使用C ++ 0x，直到从GCC支持C ++ 0x的描述中删除“实验”一词，或直到你真正需要任何C ++ 0x在某种程度上，替代实施将显着牺牲良好的设计。