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

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

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.

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

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

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:

1. 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.

2. 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.

3. 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.