为下一个 C++ 标准做准备答案

【问题标题】：Preparing for the next C++ standard为下一个 C++ 标准做准备
【发布时间】：2010-10-17 13:03:38
【问题描述】：

关于BOOST_FOREACH 的大量问题促使我询问 Boost 库的用户，他们正在做什么（如果有的话）来准备他们的代码以移植到提议的新 C++ 标准（又名 C++0x）。比如你用shared_ptr写这样的代码：

#ifdef CPPOX
#include <memory>
#else
#include "boost/shared_ptr.hpp"
#endif

还有命名空间问题 - 将来，shared_ptr 将成为 std 命名空间的一部分 - 你如何处理这个问题？

我对这些问题很感兴趣，因为我决定硬着头皮开始认真学习 boost，并且我想在我的代码中使用最佳实践。

不完全是大量的答案 - 这是否意味着这不是问题？无论如何，感谢那些回答；我接受 jalfs 的回答，因为我喜欢被建议什么都不做！

【问题讨论】：

你的意思是 C++09 对吧？它必须在 8 个月内发布 :)
@Robert：你的意思是，到目前为止，它计划在 8 个月后问世。离决赛还差得很远。但是，是的，我想很多人如果没有赶上 09 年的最后期限，他们会感到失望。（顺便说一句，我真的开始喜欢 c++0x 这个名字了。他们不能坚持下去吗？；）
好吧，我认为他们应该将其称为 C++1x 并放弃 0x，剩下的工作太多，当前状态一团糟，但如果他们不推迟截止日期，那就是8个月后要出来:)

【解决方案1】：

简单的答案是“什么都不做”。 Boost 不会删除被 0x 采用的库。所以 boost::shared_ptr 仍然存在。所以你不需要做任何事情来保持可移植性。

当然，一旦 0x 出现了，很多代码可以被简化、清理和优化，但由于还没有出现，所以这项工作还不能真正开始。你所能做的就是确保你的代码在 0x 命中时仍然可以编译......它应该，就像那样。 Boost 不会删除他们一半的库。（我没猜到。他们之前在邮件列表中已经说明了这一点）

（如果你想切换到标准的 shared_ptr，我会说时机成熟时进行简单的搜索/替换可能更容易。将#include <boost/shared_ptr.hpp> 替换为#include <memory>，将boost::shared_ptr 替换为@ 987654324@)

当然，您也可以决定要继续使用 Boost 的shared_ptr 的项目。毕竟，仅仅因为它已被添加到标准库中并不意味着您必须使用它。

【讨论】：

【解决方案2】：

由于命名空间，无需进行任何操作。如果你想使用 boost 实现，你仍然会使用 boost 命名空间。

我认为他们不会冒险以如此大的方式破坏与以前版本的兼容性。

当然，如果您在代码中大量使用命名空间，您可能会有一些重叠的定义。您必须在每次使用时明确指定命名空间。

【讨论】：

【解决方案3】：

在 C++0x 和 Boost 之间使用共享部分的最佳方法是使用 Boost.TR1，即；如果技术报告已被接受，则执行。 Boost.TR1 将在编译器可用时使用编译器提供的实现，否则使用 Boost 提供的实现。这是 Boost.TR1 的主要目标

“TR1 库提供标准库扩展的 C++ 技术报告的实现。该库本身并不实现 TR1 组件，而是一个包含标准库的 TR1 实现（如果有的话）的薄包装器，否则它将包含 Boost 库等价物，并将它们导入命名空间 std::tr1。"

【讨论】：

【解决方案4】：

考虑到以下事实，我们目前还没有：

但是，是的，我们确实在需要时使用 Boost（当然，只有在发布经过清理阶段之后我们才会使用它），就像我们使用的任何其他第三方库一样。此外，我们会根据需要使用源表单。

然而，我们正在努力在产品设计阶段更严格地采用驱动原则（例如 move-ctor 等）。

当 C++0x 标准化时肯定会有一些工作；但这也需要我们转向一些较新的编译器（vc10？），而转向新的编译器总是一项任务。

【讨论】：

【解决方案5】：

您实际上可能一直喜欢使用 Boost 版本很长一段时间。特别是如果您需要在多个平台上编译。

Boost 库在多个平台上进行了移植和测试，并且在那里（大部分时间）表现相同。

新 C++ 库的第一个供应商实现可能仍然包含小错误和性能差异，就像添加 STL 和 std 命名空间时那样一团糟。

【讨论】：