![](https://secure.gravatar.com/avatar/15f5e6abf26f57e1838c29a8356ce7f8.jpg?s=120&d=mm&r=g)
-----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