On Sep 20, 2011, at 1:30 AM, Christian Stimming wrote: > Zitat von John Ralls <[email protected]>: >> [...] >> My feeling is that the first option, finishing the GObject conversion, has >> the lowest risk. I can start in on it > > Thanks for the exhaustive summary. Yes, I agree with pretty much all of your > points. Yes, I've thought about these issues every now and then as well. Yes, > the mix-up of different object systems is a major issue in the engine. > > And: Yes, moving all of our "business logic" ("engine") objects into GObject > seems to me the best compromise in terms of where to spend our current effort. > > I thought about adding C++ wrappers for our engine objects, but ones that use > glibmm's C++ wrapper around GObject. Using those will ensure that GObject's > memory management is properly mapped into the corresponding C++ object, so > that the C++ object behaves correctly. (Cutecash's C++ wrappers do not behave > correctly - they will crash as soon as a C object is deleted but the C++ > wrapper is not and is being accessed.) If I get around to this, it means any > effort on the GObject'ification of the engine will also give us appropriate > C++ wrappers in addition to the C objects with very little effort. > > Also, from my understanding having proper GObject objects enables better > wrappers into python or ruby - or at least that was one of GObject's claimed > advantages. But as you said this might have its own issues and we should > currently decide on the basis of what gives us the most benefit with our > current C code. >
No surprise to me that your C++ wrappers crash. I suspect that the only thing that keeps Gnucash from crashing routinely is that everything is instantiated at startup or at creation (for, e.g., a new transaction) and not destroyed until the book is closed... after which there aren't any attempts to access the objects. GObject, once we can move to 2.26, (RHEL6 and Debian stable are currently on 2.24), works with gobject-introspection, which should allow us to dump SWIG. But that only works if the objects are truly GObjects, so that setting the ref count to 0 actually destroys the object. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
