这通常会影响C ++ 11代码的代码可移植性。我正在谈论有一个类似于C / C ++预处理器阶段的新代码生成阶段，其中我们可以使生成的C ++代码对更大的编译器系列更“友好”。我想也许这可能会影响人们在C ++ 11中编写代码的可行性。
游戏控制台是一种平台类型的示例，您可能会遇到限制编译器，可能不支持不错的C ++ 11功能。另一个例子可能是Intel's C++ compiler。我很高兴看到英特尔一直在努力解决这个问题，看起来这对最新版本来说不是问题，但是假设某些原因需要使用旧版本编译器！
另一个半具体的例子是，我最近的一个项目是建立一个用于开发前线的差异工具;我对传统的基于行的差异感到不满，所以我构建了一个在C ++中使用diff_match_patch实现的小命令行工具。 C ++ 11已经“渗透”到胶水代码中，因为auto太酷了，但结果是我基本上不得不在Linux上构建LLVM，Clang和libc ++以便开始使用我的工具在linux上。目前还不清楚如何以源代码的形式将C ++ 11项目分发到Linux，因为在Linux上设置这个项目有点痛苦。这并不是说它无法完成，而是它过于尖锐，而且必须花费几个小时才能在那里设置工具链。 （更新：好吧，几个月/几年后，同样的小工具现在可以通过centos 7的软件包提供的GCC完美地构建，所以这是一种解脱。）
所以，如果我有一种神奇的方法来自动重构C ++ 11工具来生成老式的C ++代码，旧的编译器可以开箱即用，这可能会让一些人的生活变得更容易也许
在使用clang自动化代码重构方面取得了一些惊人的进展，这在David's answer here中得到了很好的体现，因此它让我想到也许有可能设置一个特定的 self-基于此技术的包含工具，可以有效地将C ++ 11代码模式转换为相应的非C ++ 11等价物。这里的想法是，不是将其用于通用自动重构（例如，将字符串转换为C字符串并返回字符串的隔离和重构代码），我们可以使用它来隔离不受支持的C ++的使用11个功能并将它们重构为一些代码，这些代码执行相同的操作但实际上会成功编译。
这是可能的吗？我不太熟悉C ++ 11的功能以及对降低实现相同功能的“旧”C ++的后果。当然，如果这种事情成为可能，我似乎无法做到，因为我没有（我没想到我会有）足够掌握语言以了解如何实现这一点。 / p>
我认为一个更合适的问题是，这值得努力吗？很难看出（鉴于LLVM显然非常有能力对ARM进行交叉编译）可能会阻止从使用clang到使用更直接的方法完成工作，例如交叉编译到目标paltform。我的猜测是，这只是我的偏执狂说法，我将来不必担心让我的C ++ 11代码在所有可以想象的目标平台上顺利运行，因为它们应该所有无论如何，x86，x86-64或ARM。但谁知道我的工作将在几年内完成。
答案 0 :(得分：2)
此外，g++多年来一直支持越来越多的C ++ 11。 4.8.1具有相当完整的支持，根据http://gcc.gnu.org/projects/cxx0x.html，大多数最有趣的部分已经可用更长时间（例如auto和可变参数模板在4.4中，自定义字符串文字在4.5中，并且constexprs在4.6）。
安装（或构建，如果需要）更新版本的gcc可能比尝试重构代码更容易。