On 07/31/2013 11:25 AM, Tavmjong Bah wrote:
On Wed, 2013-07-31 at 11:02 +0200, Sebastian Götte wrote:
On 07/31/2013 08:43 AM, Jon Cruz wrote:
On Jul 30, 2013, at 2:50 PM, Sebastian Götte wrote:
Hi, I'm currently having some problems allocating GObjects. I just added a class called SPPoint [0]. When I try to instantiate an object of that type (whether through SPObject/sp_object_child_added or manually from GDB using g_object_new does not matter), g_object_new returns an GObject* that contains a zero class: {g_type_instance = {g_class = 0x0}, ref_count = 0, qdata = 0x0} (this is not good as it breaks everything else about G_OBJECT). I was able to track down the problem to g_type_create_instance returning that when passed the new SPPoint type:
That might fall into the realm of places we prefer to use C++ classes instead of C-based GObject objects. Remember, the entire GObject system was implemented because C has no native object types and hierarchy support. (One interesting side-effect of past projects to convert more of our internals to C++ was to speed up performance at the same time that the architecture was cleaned up and modernized).
I need to use GObject here since this new class is part of the SPObject tree. I don't even have control about instantiating it myself, instead I create an SVG node and the whole instantiation is handled by some part of SPObject.
If it does need to be a GObject based type, then you might be missing something in the class or instance init functions.
I will have a look at it but I am pretty sure I did those right.
Thanks, jaseg
I am not really sure that using "Shiny C++" code is the way to go here. At some point, it would be nice to convert all the sp-xxx files to proper C++, removing the dependency on GObject. But having one class being done differently (via GMEMWRAP) doesn't seem to bring much benefit.
That is a valid point. I chose the C++ path since it lead to somewhat more concise code and since from a mailing list discussion a few weeks back (late march) I got the impression that this C++ification of the SPObject tree was somewhere on the roadmap for 0.49. Also, I'm just using plain C++ member functions (nothing virtual, no dynamic_cast run time type info things etc.). All of these methods could be translated more or less 1:1 to C functions and the corresponding classes still look like structs.
However I can un-shiny this code to plain C/GObject for the meantime for readability if this is too far off.
I think the GMEMWRAP macro and the template it is wrapping are a pretty good way to bridge both worlds since this really just generates a very thin static wrapper function around C++ member functions, using C++'s type system for casting (which is already used by the SPObject tree insofar as it can be used for proper casting).
Jon, perhaps you can comment further. Sebastian's code can be seen at:
https://bazaar.launchpad.net/~h-e-6/inkscape/connector-wip/files
The specific files are:
https://bazaar.launchpad.net/~h-e-6/inkscape/connector-wip/view/head:/src/sp... https://bazaar.launchpad.net/~h-e-6/inkscape/connector-wip/view/head:/src/sp... https://bazaar.launchpad.net/~h-e-6/inkscape/connector-wip/view/head:/src/go...
Tav
Thanks, Sebastian