c++0x std::shared_ptr 与 boost::shared_ptr答案

【问题标题】：c++0x std::shared_ptr vs. boost::shared_ptrc++0x std::shared_ptr 与 boost::shared_ptr
【发布时间】：2011-09-27 23:27:43
【问题描述】：

我有一个大量使用shared_ptr 和STL 的c++ 代码。一个常见的标题说

#include<boost/shared_ptr.hpp>
using boost::shared_ptr;  // for shared_ptr
using namespace std;      // for STL

我现在想切换到 c++0x 以利用语言功能，使用 gcc 4.6 和 -std=c++0x。然而，现在还有std::shared_ptr，导致未指定的shared_ptr（boost::shared_ptr 与std::shared_ptr）的歧义。

改为std::shared_ptr 时，如下所示：

#include<memory>
using namespace std;      // for STL; also imports std::shared_ptr

然后我遇到了boost::python 的问题，它仅适用于boost::shared_ptr（至少无需进一步摆弄）：

/usr/include/boost/python/object/make_ptr_instance.hpp:30:52: error: no matching function for call to 'get_pointer(const std::shared_ptr<Cell>&)'

因此我的问题是

如果有一个简单的解决方案可以解决boost::shared_ptr 和std::shared_ptr 之间的歧义（除了暂时不使用c++0x），以及
如果boost::shared_ptr 最终将只是std::shared_ptr 的别名；这会自动解决我的问题。

谢谢！

【问题讨论】：

解决方案可能是一起摆脱using namespace std。它可以像对每个 stl 元素进行全局查找和替换一样简单。
对，这将是解决方案，但 STL 的使用如此频繁以至于它会使代码的可读性大大降低；也许我可以考虑在公共标头中编写一堆using std::string; using std::vector; 等声明。 std:: 用的部件其实并不多，但是用的很频繁。
@eudoxos：需要一些时间来适应，但是代码的易用性增加了很多；另外，我发现自己只是在使用它的范围内添加using std::cout; using std::string。这增加了可读性，尤其是在不那么琐碎的情况下（using boost::phoenix::bind 或 using boost:bind 或 using boost::spirit::karma::_1 等。消除了任何歧义（对编译器和程序员而言），而不会弄乱实际代码）

标签： python c++11 boost shared-ptr python-c-api

【解决方案1】：

您需要为共享指针类定义独立函数“get_pointer”，以便它与 Boost Python 一起使用。 （请注意，这使您可以编写自己的共享指针，并且仍然可以使用 Boost Python：这是一种有意识的设计工作，以防止不同的 Boost 库紧密耦合）。

您可能会使用 boost tr1 兼容性标头来实现这一点，但我还没有尝试过。

http://boost.cowic.de/rc/pdf/tr1.pdf

当 Boost.TR1 被配置为使用您的标准库的本地 TR1 实现时，它不会做太多事情：它只包含适当的标题。

当 Boost.TR1 使用特定组件的 Boost 实现时，它包含适当的 Boost 标头和使用 using 声明在命名空间 std::tr1 中导入必要的声明。请注意，只有那些声明是一部分标准的一部分被导入：实现是故意非常严格的，不包括任何特定于 Boost 的扩展命名空间 std::tr1，以捕获用户代码中的任何可移植性错误。如果你真的需要使用特定于 Boost 的扩展，那么您应该直接包含 Boost 标头并使用命名空间 boost:: 中的声明。请注意，这种实现方式不完全符合标准，特别是不可能添加用户定义的模板特化 TR1 组件放入命名空间 std::tr1。还有一两个尚未完全符合标准的 Boost 库，任何此类不符合项都记录在 TR1 按主题部分。希望非标准行为的发生应该然而在实践中却极为罕见。

如果您使用符合标准的标头包含（在 boost/tr1/tr1 中），那么这些标头名称有时会与现有的冲突标准库头文件（例如 shared_ptr 被添加到现有标准库头文件中，而不是自己的标题）。这些标头以两种方式之一转发到您现有的标准库标头：对于 gcc，它使用#include_next，对于其他编译器，它使用宏 BOOST_TR1_STD_HEADER(header) （在 boost/tr1/detail/config.hpp 中定义）评估到#include <..>。对于大多数编译器来说，这应该可以“直接使用”，但确实意味着这些头文件永远不应放在编译器搜索路径中已经存在的名为“include”的目录中。

【讨论】：

谢谢！我认为使用 boost::python 会更复杂。好吧，现在我也使用 boost::serialization，但它似乎没有那么灵活（例如 this thread 建议复制和自定义 boost::serialization 对 boost::shared_ptr 的作用。