在生产中使用 std::tr1 是否值得？答案

【问题标题】：Is it worth using std::tr1 in production?在生产中使用 std::tr1 是否值得？
【发布时间】：2011-01-24 23:12:17
【问题描述】：

我正在使用 MS VC 2008 和一些项目英特尔 C++ 编译器 11.0。是否值得在生产中使用 tr1 功能？他们会保持新标准吗？

例如，现在我使用stdext::hash_map。 TR1 定义std::tr1::unordered_map。但在 MS 实现中，unordered_map 只是他们的stdext::hash_map，以另一种方式模板化。

【问题讨论】：

标签： c++ visual-c++ tr1 unordered-map

【解决方案1】：

是的，tr1 中的所有内容都会留在这。有些事情会在 std:: 中接受，但他们会留下来在tr1也。所以你的代码都没有一旦新标准出台就会打破完成了。

请原谅我：不，他们不会。如here所述：

在提案中添加了两个注释，以向用户明确说明，在从 TR 过渡到未来标准的过程中，TR 组件将不会保留在命名空间 std::tr1 中，并且配置宏将消失。

但值得注意的是，现在愿意支持 tr1 的编译器供应商，很可能不会把地球从你脚下拉下来，而是为你提供某种过渡方法。

【讨论】：

【解决方案2】：

我的建议是为包含您使用的 TR1 项目的命名空间使用别名。这样，当您的编译器支持时，您就可以从使用 TR1 版本“迁移”到标准版本。

namespace cpp0x = std::tr1;

cpp0x::unordered_map<std::string, int> mymap;

对于 C++0x 编译器，第一行变为：

namespace cpp0x = std;

剩下的就不用管了。

【讨论】：

【解决方案3】：

unordered_map 将在新标准中，hash_map 不会。请注意，tr1 命名空间也不是标准的。

【讨论】：

我不知道 std::tr1 不是标准的。我没有最终的 tr1 标准，但我正在查看的草案（PDF 链接）说：“由于本技术报告中描述的扩展不是 C++ 标准库的一部分，因此不应直接在命名空间中声明它们std. 除非另有说明，本技术报告中描述的所有组件均在命名空间 std::tr1 中声明。”。 open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf
@Ben TR1 不是 C++ 的规范。

【解决方案4】：

将在 C++0x 中添加的绝大多数库代码在 Boost C++ Libraries 中已经存在了很长一段时间。我强烈建议使用 Boost（即boost::unordered_map），因为它适用于大量 ISO C++ 1998 编译器，并且将继续在 C++0x 编译器上工作（可能使用编译器的内置实现）。此外，您不需要更改命名空间——而 std::tr1 中被批准的项目将被移动到 std——因为它始终在 boost:: 中可用，您不必担心关于 tr1 的哪些元素已成为标准。简而言之，Boost 是必经之路。

【讨论】：

我不会完全同意这一点。如果您使用 boost 实现，则具有可移植性优势，但您会失去特定于平台的优化和诸如 IDE 支持之类的东西（例如，在 Visual Studio 调试器中对 shared_ptr 的出色支持）。
@the_mandrill，我很确定 Boost 将使用底层标准实现（如果可用）...您是否有任何基准表明 boost 版本在标准版本可用的地方较慢？如果是这样，在什么平台上使用什么版本的 Boost？
我不知道任何基准测试，但我记得将 shared_ptr 的 boost 版本与 VS.Net 中的相比，boost 版本看起来更重量级，因为它可以引入更多文件和必须解决许多编译器中的怪癖。同时，VS.Net 可以免费针对本地编译器进行优化。我从未见过 boost 实现使用本地版本。

【解决方案5】：

对于tr1::unordered_map，请注意，哈希映射的实现可能有很多种，并且标准选择的实现非常经典......但对于您的特定任务可能不是最有效的。

不幸的是，该标准不要求实施多种策略（尽管我认为这需要大量工作）。

【讨论】：

我不清楚标准选择的实施是什么意思。该标准规定了 O() 行为，而不是实现。在关联容器中是否需要一组不同的 O() 行为？
O() 并不总是有意义的。例如，在重新散列方面。所有的 hashmap 都有分摊的常量插入，但是如果你没有动态重新散列，一些插入会非常慢（比如当你在 std::vector::push_back 上触发 realloc 时）。 O(1) 在这里提供了一些余地，如果您需要在时间紧迫的进程上执行频繁的插入，这还不够。