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