Wrapping shared pointer object with SWIG don't give access to class member functions

Question

I have a C++ CameraManager class that manages a list of Camera objects. The camera objects are managed by a std::list, as shared pointers, i.e. each list item is of type: shared_ptr < Camera > .

I can obtain a Camera from a CameraManager object as

 std::shared_ptr<Camera> c = cameraManager.getCamera();

Creating a Python module using Swig, the above is translated to python code as:

  camera = cameraManager.getCamera()

The camera Python object above, however, don't allow me to access any of the Camera classes functions. Python says is an object of type: 'Swig object of type 'std::shared_ptr *' at ####

Adding the following in the Swig interface file

%include <std_shared_ptr.i>
%shared_ptr(Camera)

before including

%include "aiCamera.h"

don't change the behavior in the resulting Python module. Any ideas what might be missing?

Additional info: The C++ code uses a typedef:

typedef CameraSP std::shared_ptr<Camera>;

The Camera class is derived from a base class, that is virtually empty.

class MVR_API MVRObject
{
public:
                                     MVRObject();
                                     MVRObject(const MVRObject& obj);
    virtual                         ~MVRObject();

};

The code is compiled using VS 2013 and CMake. The CMake code looks like this:

set_source_files_properties(${PyModule}.i PROPERTIES CPLUSPLUS ON)
set_source_files_properties(${PyModule}.i PROPERTIES SWIG_FLAGS "-threads")

SWIG_ADD_LIBRARY(${PyModule}
    TYPE MODULE 
    LANGUAGE python 
    SOURCES ${PyModule}.i
    )


SWIG_LINK_LIBRARIES (${PyModule}
    ${PYTHON_LIB_FOLDER}/Python37.lib    
    dslFoundation
    aimvr
)

# INSTALL PYTHON BINDINGS
# Get the python site packages directory by invoking python
execute_process(COMMAND python -c "import site; print(site.getsitepackages()[0])" OUTPUT_VARIABLE PYTHON_SITE_PACKAGES OUTPUT_STRIP_TRAILING_WHITESPACE)
message("PYTHON_SITE_PACKAGES = ${PYTHON_SITE_PACKAGES}")

SET(SWIG_RUNTIME ${CMAKE_CURRENT_BINARY_DIR}/mvr_swigpyrun.h)
execute_process(COMMAND ${SWIG_EXECUTABLE} -python -external-runtime ${SWIG_RUNTIME})

UPDATE: The problem was not Swig and usage of shared pointers. It was a third party library having its own implementation of shared_ptr. Resolving the shared pointers by namespace names fixed the problem and the resulting Python module started working as expected.

Answer 1

The question above are dealing with a C/C++ API from Allied Vision, controlling their cameras. They have defined their own shared pointer class and named it using the same name as the std shared pointer class, i.e. shared_ptr.

The client code for this API is using std::shared_ptr's, and at some point the usage of a shared_ptr, without specifying the namespace caused the above problems with Swig. By explicitly specifying the std namespace when using a shared_ptr, the problems were resolved and the resulting swigged objects, using shared pointers, started working perfectly fine.