On Mar 28, 2013, at 10:30 AM, Markus Engel wrote:
As such, we should make sure that we don't break the expected behaviour of GObject objects.
Well, what is the expected behavior? At the moment, the GObject type system is only needed for those casting macros that can easily be replaced by dynamic_casts and for object instantiation. Reference couting can be replaced by using shared_ptrs. I’ve got some code here where I already replaced the factory and the macros and it works, but there’s quite a lot left to do. As soon as the factory is replaced, the SP classes can simply be combined with the corresponding C classes, removing GObject from the derivations. This is not possible now because g_object_new doesn’t fill in the vtable but its own type information.
Hey Markus,
In general this sounds good. I know what you've been looking at is in line with some of the overall long-term plans we'd like to see happen. (One minor caveat on these conversions in general is that GTKmm wrapping works only from the C++ side, and not from the other direction.)
Probably the main thing we want to look at are a set of general questions that should be covered for any architecture shifts:
* how does this affect memory use? * how does this affect performance? * how does this affect code maintainability?
In this case I think the third question is pretty clearly "it helps a lot". Getting answers on the first two takes a bit of end-to-end measurements in full use cases. If you happen to have some ideas on how to check this for the change, that would be helpful. If not, then it is something that we should look into overall anyway.
One interesting point is that developer intuition is wrong 80% of the time when it comes to performance and optimization. So we need to get some actual measurements set up on the code.