c ++ 0x std :: shared_ptr vs. boost :: shared_ptr [英] c++0x std::shared_ptr vs. boost::shared_ptr

问题描述

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

I have a c++ code which heavily uses shared_ptr and STL. A common header says

#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 vs std :: shared_ptr ）。

I wanted to switch to c++0x now to make use of the language features, using gcc 4.6 with -std=c++0x. There is however std::shared_ptr now as well, leading to ambiguity for unspecified shared_ptr (boost::shared_ptr vs std::shared_ptr).

code> std :: shared_ptr ，如下所示：

When switching to std::shared_ptr instead, like this:

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

那么我会遇到 boost :: python ，只需要 boost :: shared_ptr （至少没有进一步fiddling）：

then I am getting problems with boost::python, which works apprently with boost::shared_ptr only (at least without further fiddling):

/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 的别名;这将自动解决我的问题。

• if there is a simple solution to resolve the ambiguity between boost::shared_ptr and std::shared_ptr (other than not using c++0x for now), and also
• if boost::shared_ptr will eventually be just an alias for std::shared_ptr; that would solve my problem automatically.

谢谢！

推荐答案

您需要为共享指针类定义独立的函数'get_pointer'，以使用Boost Python。 （注意，这使你能够编写自己的共享指针，并仍然使用Boost Python：这是一个有意识的设计努力，以防止紧密耦合不同的Boost库）

You need to the define the freestanding function 'get_pointer' for your shared pointer class for it to work with Boost Python. (Note that this enables you to write your own shared pointer, and still work with Boost Python: this is a conscious design effort to prevent tight coupling of distinct Boost libraries).

您可能会使用boost tr1兼容性标头，但我没有尝试过。

You might get that using the boost tr1 compatibility headers, but I haven't tried.

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

当Boost.TR1配置为使用您的标准库的本地TR1实现时，它不会做太多：it
只包括相应的头。

When Boost.TR1 is configured to make use of your standard library's native TR1 implementation, then it doesn't do very much: it just includes the appropriate header.

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

When Boost.TR1 is using the Boost implementation of a particular component, then it includes the appropriate Boost header(s) and imports the necessary declarations in namespace std::tr1 with using declarations. Note that only those declarations that are part of the standard are imported: the implementation is deliberately quite strict about not including any Boost-specific extensions in namespace std::tr1, in order to catch any portability errors in user code. If you really need to use Boost-specific extensions then you should include the Boost headers directly and use the declarations in namespace boost:: instead. Note that this style of implementation is not completely standards-conforming, in particular it is not possible to add user-defined template specializations of TR1 components into namespace std::tr1. There are also one or two Boost libraries that are not yet fully standards conforming, any such non-conformities are documented in the TR1 by subject section. Hopefully, occurrences of non-standard behavior should be extremely rare in practice however.

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

If you use the standard conforming header includes (in boost/tr1/tr1) then these header names can sometimes conflict with existing standard library headers (for example shared_ptr is added to the existing standard library header rather than it's own header). These headers forward on to your existing standard library header in one of two ways: for gcc it uses #include_next, and for other compilers it uses the macro BOOST_TR1_STD_HEADER(header) (defined in boost/tr1/detail/config.hpp) which evaluates to #include <../include/header>. This should work "straight out the box" for most compilers, but does mean that these headers should never be placed inside a directory called "include" that is already in your compiler's search path.

这篇关于c ++ 0x std :: shared_ptr vs. boost :: shared_ptr的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！