who deletes wrapped c++ object created by c++

[Anonymous]

Hi,

I have a function that looks something like this:

QList< SomeCPPObject* > SomeQObject::f() const {
  QList< SomeCPPObject* > list;
  SomeCPPObject *o = new SomeCPPObject();
  list.append(o);
  …
  return list;
}

Where SomeCppObject is being wrapped.

Questions:
- Since SomeCPPObject is created on the C++ side, who owns it and is responsible for deleting it? I assume PythonQT since there's no great way for C++ to hang onto it?
- Along these lines, I noticed I cannot pass by-value back (e.g. QList< SomeCPPObject > SomeQObject::f()). Is there a strong reason for that? In C++ QT I would tend to treat most objects like that as pass-by-value types instead of pointer types to avoid managing the memory. Unfortunately with this approach I seem forced to pointer types which complicates any C++ client that wants to use this function as well.

Thanks very much!

[Florian Link]

PythonQt does not have any knowledge about the ownership of C++ objects that are returned from C++.
This being the case, it can not delete them and the ownership stays with C++.

An alternative is to use QObjects, which are owned by their parent.

Another alternative is to use constructors, which are called from Python and thus PythonQt knows that the object is owned
by Python.

I know that it would be nicer if PythonQt could get this knowledge, but I did not yet come up with a good idea on how to
encode that in the slot naming or QMetaObject classinfo or whereever.
Looking at other systems (PySide, QtJambi), they add this knowledge in the typesystem XML file, but for PythonQt it would be nicer to add this information dynamically. If you have a good idea, please speak up!

Regarding the by-value return value, the problem is the MOC compiler of Qt, it does not support return by value, so this limitation can not be overcome.

regards,
Florian

[Anonymous]

Thanks! On that note, PythonQT basically reuses the Jambi typesystem (tho you supply the generator?) Is that basically correct? If so, then what this all seems to lead up to: if one wants more fine-grained control, then best option is to write some mappings go with the generator approach?

This is becoming more appealing to me, since I have many C++ classes that descend from QSharedData instead of QObject. Since this would also need to be passed by as pointers, I would again need a separate API to support python, not to mention having to 'manually' manage the reference counts on the C++ side to ensure the objects don't get deleted if python is using them.

[Florian Link]

Yes, I adapted the generator from qtscript, which was adapted from QtJambi. So the typesystem is basically the Qtjambi one, with minor tweaks.
BUT, the generator does not yet support ownership passing (although the typesystem files contain the information),
so the generator would need to generate special code that calls into PythonQt to tell it about ownership passing.

It is not on my TODO list right now and would require some more thoughts.