2013/7/31 Markus Engel <p637777@...1081...>:
However, using it would require you to rewrite the init functions of all
SPObjects. ...
Replacing GObject-style initialization with constructor / destructor
shims in the style of NRObject would considerably simplify removing the GObject dependency later and reduce the burden of maintaining the init / dispose functions.
Well, please don't do that, I'm already done removing the GObject dependency, take a look at my branch at https://code.launchpad.net/~engelmarkus/inkscape/cppify .
Some review comments about this branch
1. The code seems wrong in a several places. For example, the constructor of SPObject retains the manual constructor calls and its destructor retains the manual destructor calls. Member initialization is already done before the constructor is even entered, and member destruction happens automatically after the destructor returns. I'm fairly sure this will lead to problems at runtime.
2. A lot of the constructor code should be changed to member initializers. See e.g. the constructor of SPItem.
3. Class names such as CSomething are reminiscent of MFC. The prefixes should be removed and the classes put in namespace Inkscape::SVG (since they represent objects in the SVG).
4. "#pragma once" is not used in existing Inkscape code. For consistency you should use standard include guards.
5. singleton.h should be merged into sp-factory.h. Singletons should be avoided where possible, so a separate singleton header is not a good idea. Boost doesn't have a singleton header for the same reason.
6. Method and variable names are not consistent with our coding style, though this could be addressed later since it's a leftover of previous GObject code. http://staging.inkscape.org/en/develop/coding-style/ http://inkscape.org/doc/coding_style.php (old website)
7. The virtual methods should be made protected, since they are not intended for use outside of SP node implementations.
Since the initialization rework I proposed would address points 1 and 2, it seems that this part of the work is actually not done.
What do others think? Should we work from Markus' code or rewrite the initialization first? Should we release 0.49 before introducing this kind of changes?
Regards, Krzysztof