Prevent nested C++ struct from being deleted when parent is GC'd - c++

Question

Here is a pretty trivial example of the problem I'm having. struct Foo contains struct Bar which contains one int. If a Foo is garbage collected, then its inner Bar is also removed, even if there are still references to that bar.
Python code
import example
def get_bar():
foo = example.Foo()
foo.bar.x = 10
bar = foo.bar
print("before {}".format(bar.x))
return foo.bar # foo (and bar) are deleted when this returns
bar = get_bar()
print("after {}".format(bar.x))
Output
> before 10
> after 39656152
I've eliminated all pointers and references from the C++ code, hoping that SWIG would use the same value semantics, but it is still internally converting things to Foo* and Bar*. I guess my question is, how can I convince SWIG to make a copy of bar in _wrap_Foo_bar_get?
Example code below:
example.h
struct Bar {
int x;
};
struct Foo {
Bar bar;
};
example.i
%module "example"
%{
#include "example.h"
%}
%include "example.h"
CMakeLists.txt
FIND_PACKAGE(SWIG REQUIRED)
INCLUDE(${SWIG_USE_FILE})
FIND_PACKAGE(PythonLibs)
INCLUDE_DIRECTORIES(${PYTHON_INCLUDE_PATH} .)
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR})
SET(CMAKE_SWIG_FLAGS "")
SET_SOURCE_FILES_PROPERTIES(example.i PROPERTIES CPLUSPLUS ON)
SET_SOURCE_FILES_PROPERTIES(example.i PROPERTIES SWIG_FLAGS "-includeall")
SWIG_ADD_MODULE(example python example.i example.h)
SWIG_LINK_LIBRARIES(example ${PYTHON_LIBRARIES})
And here is the generated SWIG method that is grabbing a reference to bar rather its value:
SWIGINTERN PyObject *_wrap_Foo_bar_get(PyObject *SWIGUNUSEDPARM(self), PyObject *args) {
PyObject *resultobj = 0;
Foo *arg1 = (Foo *) 0 ;
void *argp1 = 0 ;
int res1 = 0 ;
PyObject * obj0 = 0 ;
Bar *result = 0 ;
if (!PyArg_ParseTuple(args,(char *)"O:Foo_bar_get",&obj0)) SWIG_fail;
res1 = SWIG_ConvertPtr(obj0, &argp1,SWIGTYPE_p_Foo, 0 | 0 );
if (!SWIG_IsOK(res1)) {
SWIG_exception_fail(SWIG_ArgError(res1), "in method '" "Foo_bar_get" "', argument " "1"" of type '" "Foo *""'");
}
arg1 = reinterpret_cast< Foo * >(argp1);
result = (Bar *)& ((arg1)->bar);
resultobj = SWIG_NewPointerObj(SWIG_as_voidptr(result), SWIGTYPE_p_Bar, 0 | 0 );
return resultobj;
fail:
return NULL;
}

Answer 1

SWIG (and Boost Python) are fighting an uphill battle by interfacing between languages with very different data models. You are making that battle that much harder (unwinnable) by expecting those SWIG-wrapped objects to behave exactly like other Python objects. They don't because they can't. The C++ and Python data models are quite different.
In C++, that Bar instance that is embedded within class Foo is an integral part of a Foo object. The memory occupied by that embedded Bar object is a part of the overall memory for that containing Foo object. When foo goes out of scope and is destructed, foo.bar must necessarily go out of scope and be destructed along with it's containing object. Your foo.bar is not detachable from foo. The two objects have identical lifespans.
That's not the case in Python. A Python object that contains a sub-object doesn't contain that sub-object in the C++ sense. The memory for the containing and contained objects are distinct and non-overlapping. The containing object instead has a reference to the contained sub-object. This makes those sub-objects in Python detachable from the objects that contain them. Just get a separate reference reference to that sub-object and voila!, the containing and contained objects have different life spans.
One way around this problem is to use smart pointers in your C++ code. SWIG does support these to some extent. Another way around this problem is to never let it rear its ugly head. Be aggressive with data hiding in the code that you are exposing to SWIG. The problem never arises if that Bar object embedded within that Foo object is properly hidden. Use the member functions, not the member data, and you'll be much better off.
One final word: There is another, somewhat kludgy, way around this problem, and that's to use the thisown attribute. Had you set foo.thisown = 0 in your Python function get_bar you wouldn't have had this problem. You would have had a leak, however.