【发布时间】：2013-07-04 22:25:58
【问题描述】：
这通常会影响 C++11 代码的代码可移植性。我说的是有一个类似于 C/C++ 预处理器阶段的新代码生成阶段，我们可以使生成的 C++ 代码对更大的编译器系列更加“友好”。我认为这可能会影响将人们转移到使用 C++11 进行编码的可行性。
游戏机是一种平台类型的示例，您可能会遇到限制编译器，可能不支持不错的 C++11 功能。另一个例子可能是Intel's C++ compiler。我很高兴看到英特尔一直在努力解决这个问题，看起来这在最新版本上不是问题，但假设出于某些原因需要使用旧版本的编译器！
另一个半具体的例子，是我最近的一个项目是构建一个 diff 工具，供开发中的一线使用；我对传统的基于行的差异感到不满意，所以我构建了一个小命令行工具，它使用 C++ 中的diff_match_patch 实现。 C++11 已经“渗透”到胶水代码中，因为 auto 太酷了，但结果是我基本上不得不在 Linux 上构建 LLVM、Clang 和 libc++ 才能开始在 Linux 上使用我的工具.甚至不清楚如何以源代码形式将 C++11 项目分发到 Linux，因为在 Linux 上设置 clang 有点考验人。这并不是说它不能完成，而是它太先进了，一个人必须花几个小时才能在那里设置工具链。 （更新：嗯，几个月/几年后，同样的小工具现在可以完美地与 centos 7 软件包提供的 GCC 构建，所以这是一种解脱。）
所以，如果我有一种神奇的方法来自动重构 C++11 工具以生成旧式编译器可以立即接受的老式 C++ 代码，这可能会让某些人的生活变得更轻松一些也许吧。
在使用 clang 自动重构代码方面取得了一些惊人的进展，这在 David's answer here 中得到了很好的介绍，所以它让我想到也许有可能建立一个特定的 自包含工具 基于这种技术，可以有效地将 C++11 代码模式转换为相应的非 C++11 等价物。这里的想法是，与其将其用于通用自动重构（例如，隔离和重构将字符串转换为 C 字符串并返回字符串的代码），我们也许可以将其用于隔离不受支持的 C++ 的使用11 个特性，并将它们重构为一些代码，这些代码做同样的事情，但实际上会成功编译。
这是可能的吗？我不太熟悉 C++11 的功能以及降级到实现相同功能的“旧”C++ 的后果。看起来如果这种事情是可能的，我就做不到，因为我没有（我也不希望我永远有）足够的语言掌握来知道如何实现这一点。
我想一个更合适的问题是，这值得付出努力吗？很难看出如何（鉴于 LLVM 显然非常有能力交叉编译到 ARM）可能会被阻止从使用 clang 到使用更直接的方法完成工作，例如交叉编译到目标平台。我的猜测是，这只是我的妄想症，将来我真的不需要担心让我的 C++11 代码在所有可能的目标平台上顺利运行，因为它们应该 all无论如何，x86、x86-64 或 ARM。但谁知道几年后我的工作会是什么。
【问题讨论】：
-
该死的，问题确实已经被问过了。
-
不要转换代码，而是查看
boost.config之类的东西来处理编译器差异。 -
基本上，您要求用您使用 C++11 的痛苦来换取其他人构建 C++11 到传统 C++ 转换器的痛苦。作为对工具特别是翻译器感兴趣的人，并且恰好拥有 C+11 和遗留 C 前端以及通用翻译器机器，我可能就是您正在考虑的人。我理解你的动机。什么是我的？
-
@JesseGood 您能否详细说明
boost.config对此有何帮助？
标签： c++ c++11 compilation portability automated-refactoring