Hi,


I’m working on Mod Organizer’s Python-based plugin support. If anyone needs
context, the base branch is at https://github.com/
Modorganizer2/modorganizer-plugin_python and my expansion is at
https://github.com/AnyOldName3/modorganizer-plugin_python/tree/implement-
more-interfaces-2. Headers that get exposed to Python live in another
repository at https://github.com/Modorganizer2/modorganizer-
uibase/tree/Develop/src



As part of my general tidying up of things, I found and replaced an
incomplete boost::python::class_ definition for QDir which should have been
using SIP/PyQt5 as it’s a Qt class. The change is https://github.com/
AnyOldName3/modorganizer-plugin_python/commit/8dd9a710b4a963d850a8b60a6b7919
bc0af0aa8f



This broke some things (and lead me to realise some other things were
already broken). Specifically, I noticed that when a C++ function returns a
Qt class by value and this function gets called from Python, the C++ part
goes out of scope and is deallocated, despite still being used in Python.
This is happening because the to-Python converter for these classes (
https://github.com/AnyOldName3/modorganizer-plugin_python/blob/implement-
more-interfaces-2/src/runner/pythonrunner.cpp#L500) is building the Python
object around the existing C++ object instead of copy constructing a new
one, and I guess to-Python converters are supposed to create something that
will work even once the object being converted is deallocated.
Unfortunately, that isn’t an option here, as some Qt types can’t be copy
constructed (and even if they could, stuff might break which expected the
thing it received to stay in sync).



What I’d like to be able to do is register separate to-Python converters,
some of which require the C++ object to be kept alive, but return an
l-value, and others which make a copy of the C++ object (although if Boost
could use the former as the latter by doing the copying itself, that would
be good, too). I can prevent these from leaking memory as SIP has the
ability to let me transfer ownership at will. As far as I can tell, this
option doesn’t exist. I wouldn’t be too surprised if some other workaround
existed, but I don’t know what to put into Google to make it appear. I
suppose it might be possible to make wrappers returning pointers for all
functions that return by value, but I don’t know how I’d make a static
function a boost::python::class_ member function.



Any help would be greatly appreciated,



Many thanks,



AnyOldName3



PS: If you do go looking through the whole repository rather than focusing
on the specific bits I mentioned, don’t blame me for weirdness like there
being wrappers for classes which will never be extended in Python as this
project is years old, and I’ve only been working on it for a little bit.
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig

Reply via email to