Hello all inkscape developers and users,
I am currently developing the project named "C++ifying the SP Layer and XML node privatization". I had been doing the development for the same for about a month now and have created a branch for the corresponding developed code. The code as of now c++ifies sp-item.h/cpp , sp-line.h/cpp, sp-polyline.h/.cpp and marks the beginning of document.h/.cpp . There are some performance increase but they shall become more noticeable when I attack the major parent classes like SPDekstop, SPDocument(SPItem already done, took me 2 weeks). The branch is uploaded here https://code.launchpad.net/~spyzer-abhishek0/+junk/gsoc-cppify
I shall be glad to have responses about the work from the developers. I shall soon be beginning the XML node privatization as well where the main job would be to highlight the areas where XML tree should be targeted to begin its purging.
Hope this finds you all to your best.
Have a nice day!!!
-----Original Message----- From: Abhishek Sharma [mailto:spyzer.abhishek0@...400...] Sent: 29 June 2010 20:19
Hello all inkscape developers and users,
I am currently developing the project named "C++ifying the SP Layer
and
XML node privatization". I had been doing the development for the same for about a month now and have created a branch for the corresponding developed code. The code as of now c++ifies sp-item.h/cpp , sp- line.h/cpp, sp-polyline.h/.cpp and marks the beginning of document.h/.cpp . There are some performance increase but they shall become more noticeable when I attack the major parent classes like SPDekstop, SPDocument(SPItem already done, took me 2 weeks). The
branch
is uploaded here https://code.launchpad.net/~spyzer-abhishek0/+junk/gsoc-cppify
I shall be glad to have responses about the work from the developers.
I
shall soon be beginning the XML node privatization as well where the main job would be to highlight the areas where XML tree should be targeted to begin its purging.
Hi Abishek,
Great work! I hope you were able to script a lot of the work. I see you still have the SPItemClass class next to SPItem, for the C-like 'virtual' functions. Are you planning on making those functions real virtual functions of the SPItem class?
Ciao, Johan
Oh no. My mentor JonCruz told me that adding virtual functions in c++ way might break things as c has fixed addresses and all, and so making virtual functions(dynamic allocation) might infict a blow on the those current functionalities.
On Fri, Jul 2, 2010 at 3:41 AM, <J.B.C.Engelen@...1578...> wrote:
-----Original Message----- From: Abhishek Sharma [mailto:spyzer.abhishek0@...400...] Sent: 29 June 2010 20:19
Hello all inkscape developers and users,
I am currently developing the project named "C++ifying the SP Layer
and
XML node privatization". I had been doing the development for the same for about a month now and have created a branch for the corresponding developed code. The code as of now c++ifies sp-item.h/cpp , sp- line.h/cpp, sp-polyline.h/.cpp and marks the beginning of document.h/.cpp . There are some performance increase but they shall become more noticeable when I attack the major parent classes like SPDekstop, SPDocument(SPItem already done, took me 2 weeks). The
branch
is uploaded here https://code.launchpad.net/~spyzer-abhishek0/+junk/gsoc-cppify
I shall be glad to have responses about the work from the developers. I shall soon be beginning the XML node privatization as well where the main job would be to highlight the areas where XML tree should be targeted to begin its purging.
Hi Abishek,
Great work! I hope you were able to script a lot of the work. I see you still have the SPItemClass class next to SPItem, for the C-like 'virtual' functions. Are you planning on making those functions real virtual functions of the SPItem class?
Ciao, Johan
-----Original Message----- From: Abhishek Sharma [mailto:spyzer.abhishek0@...400...] Sent: Friday, July 02, 2010 03:56
Oh no. My mentor JonCruz told me that adding virtual functions in c++ way might break things as c has fixed addresses and all, and so making virtual functions(dynamic allocation) might infict a blow on the those current functionalities.
I don't understand what you mean. I think that C++ virtual functions work exactly like the way they are done C-style in Inkscape; the great advantage of C++ virtual functions is less typing less errors imho. But, then again, it is very rare that I am right and Jon is wrong, so... Jon, enlighten me! ;)
Thanks, Johan
As we all know that behavior of a virtual function only comes into picture at run-time(In other words the memory addresses and other info regarding the function is not available at compile time). Now since the inkscape codebase has been forked out of sodi-podi written in c, many of the gtk-based functionalities require "compile-time" memory based locations and not dynamic run time ones. Therefore introducing virtual functions will most probably break down the functionalities of the existing gtk code in the codebase, as Jon told me. :)
On Fri, Jul 2, 2010 at 1:14 PM, <J.B.C.Engelen@...1578...> wrote:
-----Original Message----- From: Abhishek Sharma [mailto:spyzer.abhishek0@...400...] Sent: Friday, July 02, 2010 03:56
Oh no. My mentor JonCruz told me that adding virtual functions in c++ way might break things as c has fixed addresses and all, and so making virtual functions(dynamic allocation) might infict a blow on the those current functionalities.
I don't understand what you mean. I think that C++ virtual functions work exactly like the way they are done C-style in Inkscape; the great advantage of C++ virtual functions is less typing less errors imho. But, then again, it is very rare that I am right and Jon is wrong, so... Jon, enlighten me! ;)
Thanks, Johan
-----Original Message----- From: Abhishek Sharma [mailto:spyzer.abhishek0@...400...] Sent: Friday, July 02, 2010 16:16 To: Engelen, J.B.C. (Johan) Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] GSOC branch for c++ification of the SP Layer.
As we all know that behavior of a virtual function only comes into picture at run-time(In other words the memory addresses and other info regarding the function is not available at compile time). Now since the inkscape codebase has been forked out of sodi-podi written in c, many of the gtk-based functionalities require "compile-time" memory based locations and not dynamic run time ones. Therefore introducing virtual functions will most probably break down the functionalities of the existing gtk code in the codebase, as Jon told me. :)
(excuse me for stating what I think to understand about virtual methods as facts:) The location of the virtual functions is known at compile-time. Really, it works the same as is coded now in Inkscape in C-style. The address of a virtual method is as static as non-virtual method. I think you are confusing the address of a virtual method and the address of the function that is actually called. The last one is resolved at run-time, reading the object's vtable. The address of a virtual method "&Base::virtmethod" is static, and known during compilation.
Can you point me to specific GTK code you are worried about?
Cheers, Johan
On Jul 2, 2010, at 8:27 AM, <J.B.C.Engelen@...1578...> wrote:
(excuse me for stating what I think to understand about virtual methods as facts:) The location of the virtual functions is known at compile-time. Really, it works the same as is coded now in Inkscape in C-style. The address of a virtual method is as static as non-virtual method. I think you are confusing the address of a virtual method and the address of the function that is actually called. The last one is resolved at run-time, reading the object's vtable. The address of a virtual method "&Base::virtmethod" is static, and known during compilation.
Can you point me to specific GTK code you are worried about?
Yes.
The vtable is the main issue here.
If a class has no virtual functions and no vtable, then it's memory layout is equivalent to a C struct. However...
... once you add a virtual function into the mix, object instances generally get a hidden pointer to the appropriate vtable. That hidden pointer bumps things around and confuses C code that is expecting a precise memory layout.
A simple test to run is to have two classes with identical methods and members. Give the test program two local variables, one of each class. Dump the size of them. They shouldn't match. (usually the one with virtuals is larger by sizeof(void*) ).
The gtkmm library avoids problems with such things by leaving GObjects as raw C/GTK ones and then adding C++ wrapper peer classes for each. So you operate on the hierarchy of C++ object instances, but each of those is not really a GTK object but instead holds a pointer to a true GTK object.
The SPObject stuff actually mucks with the raw C structs being passed in and out of GTK, so we have to play by their rules... including not adding that hidden pointer for the vtable.
-----Original Message----- From: Jon Cruz [mailto:jon@...18...] Sent: 02 July 2010 22:19
On Jul 2, 2010, at 8:27 AM, <J.B.C.Engelen@...1578...> wrote:
(excuse me for stating what I think to understand about virtual
methods
as facts:) The location of the virtual functions is known at compile-time.
Really,
it works the same as is coded now in Inkscape in C-style. The
address
of
a virtual method is as static as non-virtual method. I think you are confusing the address of a virtual method and the address of the function that is actually called. The last one is resolved at run-
time,
reading the object's vtable. The address of a virtual method "&Base::virtmethod" is static, and known during compilation.
Can you point me to specific GTK code you are worried about?
Yes.
The vtable is the main issue here.
If a class has no virtual functions and no vtable, then it's memory layout is equivalent to a C struct. However...
... once you add a virtual function into the mix, object instances generally get a hidden pointer to the appropriate vtable. That hidden pointer bumps things around and confuses C code that is expecting a precise memory layout.
A simple test to run is to have two classes with identical methods and members. Give the test program two local variables, one of each class. Dump the size of them. They shouldn't match. (usually the one with virtuals is larger by sizeof(void*) ).
The gtkmm library avoids problems with such things by leaving GObjects as raw C/GTK ones and then adding C++ wrapper peer classes for each.
So
you operate on the hierarchy of C++ object instances, but each of
those
is not really a GTK object but instead holds a pointer to a true GTK object.
The SPObject stuff actually mucks with the raw C structs being passed in and out of GTK, so we have to play by their rules... including not adding that hidden pointer for the vtable.
Ah, so it's not the functions' addresses, but the size of the object. OK. It's a pity :( Do we really need this GObject stuff? (if opening can of worms, please close it and ignore the question)
Ciao, Johan
2010/7/2 Jon Cruz <jon@...18...>:
Yes.
The vtable is the main issue here.
If a class has no virtual functions and no vtable, then it's memory layout is equivalent to a C struct. However...
... once you add a virtual function into the mix, object instances generally get a hidden pointer to the appropriate vtable. That hidden pointer bumps things around and confuses C code that is expecting a precise memory layout.
So what exactly is this "C++ification" intended to do? Syntax support for virtual functions is one of the main advantages of moving to C++.
I also thought the goal is to move off GObject for the SP tree, so rewriting functionality dependent on GObject should be part of the project.
Regards, Krzysztof
On Jul 3, 2010, at 10:02 PM, Krzysztof Kosiński wrote:
So what exactly is this "C++ification" intended to do? Syntax support for virtual functions is one of the main advantages of moving to C++.
I also thought the goal is to move off GObject for the SP tree, so rewriting functionality dependent on GObject should be part of the project.
Removal of GObject is going to be one of the last things we can do to our codebase. So much of it is dependent on the GTK/GObject approach, that it is a very large job to get there. Additionally the virtual function support is actually not nearly as much of an advantage as one might think, given that GTK/GObject already give us a fairly robust and mature object oriented framework. Other aspects of C++ bring much more benefit to our codebase (type safety, explicit casting, templates, etc).
Things are being approached in a cyclical iterative manner, with several other things happening in early passes. One of the first things to do is increase encapsulation and modularity while reducing extraneous cross-dependencies.
Moving random functions to be class members, making members private, etc. are all happening in the first pass. Basically that is the same work being done with GTK itself in their move to 3.x and going through and "sealing" members.
Basically this issue is very similar to that encountered with cleaning up the Y-axis inversion. On the surface it might seem like a very simple job. However once it gets looked into, the details stat to crop up all over that reveal the scope of work to be far more than one might initially guess. Getting that Y-axis cleaned up has been happening bit by bit over several years, and we're finally *close* to the point of being able to finish it.
W dniu 4 lipca 2010 08:29 użytkownik Jon Cruz <jon@...18...> napisał:
Basically this issue is very similar to that encountered with cleaning up the Y-axis inversion. On the surface it might seem like a very simple job. However once it gets looked into, the details stat to crop up all over that reveal the scope of work to be far more than one might initially guess.
I don't want to be overly critical but so far the changes amount to mechanical replacement of "return_type sp_foo_method(SPFoo *, args...)" with "return_type method(args...)" and replacing "struct SPFoo" with "class SPFoo". This includes deprecated methods like sp_item_invoke_bbox_full with NRRect arguments. It would be more useful to identify a few places in the code with a dependency on GObject and rewrite them to eliminate that dependency.
Three other problems: 1. Why are sp_foo_method left commented out at the bottom of the headers? 2. Abhishek's changes use tabs instead of 4 spaces. 3. New methods do not follow coding guidelines (should be camelCase instead of lowercase_with_underscores).
Regards, Krzysztof
Quick note, this thread (after my message) is to be taken into off-list territory. Thank you!
Cheers, Josh
On Sun, 2010-07-04 at 09:55 +0200, Krzysztof Kosiński wrote:
W dniu 4 lipca 2010 08:29 użytkownik Jon Cruz <jon@...18...> napisał:
Basically this issue is very similar to that encountered with cleaning up the Y-axis inversion. On the surface it might seem like a very simple job. However once it gets looked into, the details stat to crop up all over that reveal the scope of work to be far more than one might initially guess.
I don't want to be overly critical but so far the changes amount to mechanical replacement of "return_type sp_foo_method(SPFoo *, args...)" with "return_type method(args...)" and replacing "struct SPFoo" with "class SPFoo". This includes deprecated methods like sp_item_invoke_bbox_full with NRRect arguments. It would be more useful to identify a few places in the code with a dependency on GObject and rewrite them to eliminate that dependency.
Three other problems:
- Why are sp_foo_method left commented out at the bottom of the headers?
- Abhishek's changes use tabs instead of 4 spaces.
- New methods do not follow coding guidelines (should be camelCase
instead of lowercase_with_underscores).
Regards, Krzysztof
This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Jul 4, 2010, at 12:55 AM, Krzysztof Kosiński wrote:
I don't want to be overly critical but so far the changes amount to mechanical replacement of "return_type sp_foo_method(SPFoo *, args...)" with "return_type method(args...)" and replacing "struct SPFoo" with "class SPFoo". This includes deprecated methods like sp_item_invoke_bbox_full with NRRect arguments. It would be more useful to identify a few places in the code with a dependency on GObject and rewrite them to eliminate that dependency.
Not really.
There are some subtle modularity and encapsulation changes that are also going in. Those are easy to miss on the surface.
And, no, it's not more useful to target GObject at this time. There are far more than just "a few", and more importantly there are subtle *logic* issues with different approaches that need to change.
Three other problems:
- Why are sp_foo_method left commented out at the bottom of the headers?
Simple working practice. He's been keeping things in as he roughs in the work, and will remove them later. He finds it easier to work on the new changes while having the old code there to refer to.
- Abhishek's changes use tabs instead of 4 spaces.
A very minor cosmetic issue that is simple to address later on. Getting things functional is far more important than a simple M-x untabify being left for later.
- New methods do not follow coding guidelines (should be camelCase
instead of lowercase_with_underscores).
Yes, this has been intentional. He has been planning on tuning the names later on. At the moment leaving some of those as-is brings several benefits. Among those are easier merging and more helpful visual diffs.
participants (5)
-
unknown＠example.com -
Abhishek Sharma -
Jon Cruz -
Joshua A. Andler -
Krzysztof Kosiński