swig/python std::shared_ptr

SWIG-1.3 Documentationにsmart pointerに対する言及はあるけど、std::shared_ptrに対するそれは無い。

% find /usr/share/swig1.3/ -name "*shared_ptr.i"
/usr/share/swig1.3/octave/boost_shared_ptr.i
/usr/share/swig1.3/java/boost_shared_ptr.i
/usr/share/swig1.3/python/boost_shared_ptr.i
/usr/share/swig1.3/shared_ptr.i
/usr/share/swig1.3/csharp/boost_shared_ptr.i

がしかし、ちゃんとある。

#define SWIG_SHARED_PTR_NAMESPACE std
%include <python/boost_shared_ptr.i>

%feature("smartptr", noblock=1) hogeptr { std::shared_ptr<hoge> }

SWIG_SHARED_PTR(hogeptr, hoge);

std::tr1な時は、さらに#define SWIG_SHARED_PTR_SUBNAMESPACE tr1

>http://www.swig.org/Release/CHANGES

02/09/2008: wsfulton
            [Python] Experimental shared_ptr typemaps added. Usage is the same as the recently
            added Java and C# shared_ptr typemaps. Two macros are available, although these
            may well change in a future version:

            For base classes or classes not in an inheritance chain:
              SWIG_SHARED_PTR(PROXYCLASS, TYPE)
            For derived classes:
              SWIG_SHARED_PTR_DERIVED(PROXYCLASS, BASECLASSTYPE, TYPE)

            The PROXYCLASS is the name of the proxy class, but is only required for Java/C#.
            Example usage:

              %include "boost_shared_ptr.i"

              SWIG_SHARED_PTR(Klass, Space::Klass)
              SWIG_SHARED_PTR_DERIVED(KlassDerived, Space::Klass, Space::KlassDerived)

              namespace Space {
                struct Klass { ... };
                struct KlassDerived : Klass { ... };
              }

            Further details to follow in future documentation, but the following features
            should be noted:

            - Not restricted to boost::shared_ptr, eg std::tr1::shared_ptr can also be used.
            - Available typemap groups:
              (a) Typemaps for shared_ptr passed by value, reference, pointer and pointer 
                  reference.
            - (b) Typemaps for passing by raw value, raw pointer, raw reference, raw pointer
                  reference. 
            - The code being wrapped does not even have to use shared_ptr, SWIG can use
              shared_ptr as the underlying storage mechanism instead of a raw pointer due to 
              the typemaps in group (b) above.
            - No array support as shared_ptr does not support arrays.
            - This works quite differently to the usual SWIG smart pointer support when
              operator-> is parsed by SWIG:
              - An additional smart pointer class is not generated reducing code bloat in
                the wrappers.
              - Using smart pointers and raw pointers can be mixed seamlessly.
              - Missing constructors for the smart pointers is no longer a problem and so
                separate factory type functions do not have to be written and wrapped.
              - The implicit C++ shared_ptr< derived class > to shared_ptr< base class >
                cast also works in the target language. This negates the necessity to write
                an explicit helper cast function providing the upcast which would need
                calling prior to passing a derived class to a method taking a shared_ptr to
                a base class.
02/09/2008: wsfulton
            [Python] Add support for overriding the class registration function via a new
            "smartptr" feature. This is a very low level of customisation most users
            would never need to know. The feature will typically be used for intrusive 
            smart pointers along with additional typemaps. Example usage of the feature:

              %feature("smartptr", noblock=1) Foo { boost::shared_ptr< Foo > }
              class Foo {};

            The generated Foo_swigregister function will then register boost::shared < Foo >
            (SWIGTYPE_p_boost__shared_ptrTFoo_t instead of SWIGTYPE_p_Foo) as the underlying
            type for instantiations of Foo.
02/09/2008: wsfulton
            Features now supports the optional 'noblock' attribute for all usage of %feature. 
            When specified, the { } braces are removed from the feature code. This is identical
            in behaviour to usage of 'noblock' in typemaps and is used when the preprocessor
            is required to operate on the code in the feature and the enclosing { } braces
            are not required. Example:

              #define FOO foo
              %feature("smartptr", noblock="1") { FOO::bar }

            The preprocessor then reduces this as if this had been used instead:

              %feature("smartptr") "foo::bar"

SWIGすごい！

追記
http://www.nabble.com/Correct-Python-reference-counting-with-directors--td23046686.html
>The python shared_ptr support does not include directors.
涙目。