Are vtables of interfaces always correctly initialized?

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

This question is related to goocanvasmm bug 606357
(https://bugzilla.gnome.org/show_bug.cgi?id=606357).

Inheritance structure of involved classes:
  class Goocanvas::Item : public Glib::Interface
  class Goocanvas::ItemSimple :
    public Glib::Object, public Goocanvas::Item
  class Rect : public Goocanvas::ItemSimple

The description of the bug says:

"When I create a canvas item derived from Goocanvas::ItemSimple, my
application crashes with a segmentation violation on exit (or whenever I
try to clear the custom items canvas).  This crash does not occur if my
object is derived from Goocanvas::Rect or Goocanvas::Ellipse."

The crash occurs in the virtual function
  void Goocanvas::Item::set_canvas_vfunc(Canvas* canvas).

I have explained in the bug how to fix the crash. That's not the issue
here. What made me have a closer look at the bug was the statement that
the crash does *not* occur in a user-derived object, derived from
Goocanvas::Rect. The reason turns out to be that
Item_Class::set_canvas_vfunc_callback() is not called, because
Item_Class::iface_init_function() is not called, because
Item_Class::init() is not called, because
Item::add_interface() is not called, because
ItemSimple_Class::init() is not called, because the default ctor
ItemSimple::ItemSimple() is not called.

I tested goocanvasmm/examples/custom_item and a modified version of it.
Compare these two backtraces.

1. class ExampleItem : public Goocanvas::ItemSimple

#0  Goocanvas::Item_Class::set_canvas_vfunc_callback (self=0x80f3608,
canvas=0x80f2040) at item.cc:1247
#1  0x006efb10 in goo_canvas_item_set_canvas (item=0x80f3608,
canvas=0x80f2040) at goocanvasitem.c:578
#2  0x006f75ca in goo_canvas_item_simple_set_parent (item=0x80f3608,
parent=0x80bd8a0) at goocanvasitemsimple.c:840
#3  0x00fc587b in Goocanvas::Item::set_parent_vfunc (this=0x80f634c,
parent=...) at item.cc:3696
#4  0x00fc9c9b in Goocanvas::Item_Class::set_parent_vfunc_callback
(self=0x80f3608, parent=0x80bd8a0) at item.cc:1617
#5  0x006efefa in goo_canvas_item_set_parent (item=0x80f3608,
parent=0x80bd8a0) at goocanvasitem.c:763
#6  0x006ec9df in goo_canvas_group_add_child (item=0x80bd8a0,
child=0x80f3608, position=0) at goocanvasgroup.c:349
#7  0x006efb6e in goo_canvas_item_add_child (item=0x80bd8a0,
child=0x80f3608, position=-1) at goocanvasitem.c:601
#8  0x00fc3e56 in Goocanvas::Item::add_child (this=0x80797ac, child=...)
at item.cc:51
#9  0x0804eea1 in ExampleWindow::ExampleWindow (this=0xbfffed60,
__in_chrg=<value optimized out>, __vtt_parm=<value optimized out>)

2. class ExampleItem : public Goocanvas::Rect

#0  goo_canvas_item_simple_set_canvas (item=0x80f4818, canvas=0x80f3040)
at goocanvasitemsimple.c:819
#1  0x006efb10 in goo_canvas_item_set_canvas (item=0x80f4818,
canvas=0x80f3040) at goocanvasitem.c:578
#2  0x006f75ca in goo_canvas_item_simple_set_parent (item=0x80f4818,
parent=0x80be8a0) at goocanvasitemsimple.c:840
#3  0x006efefa in goo_canvas_item_set_parent (item=0x80f4818,
parent=0x80be8a0) at goocanvasitem.c:763
#4  0x006ec9df in goo_canvas_group_add_child (item=0x80be8a0,
child=0x80f4818, position=0) at goocanvasgroup.c:349
#5  0x006efb6e in goo_canvas_item_add_child (item=0x80be8a0,
child=0x80f4818, position=-1) at goocanvasitem.c:601
#6  0x00fc3e56 in Goocanvas::Item::add_child (this=0x80f78ac, child=...)
at item.cc:51
#7  0x0804f0a1 in ExampleWindow::ExampleWindow (this=0xbfffed60,
__in_chrg=<value optimized out>, __vtt_parm=<value optimized out>)
    at custom_item/examplewindow.cc:42

Now Goocanvas::Item_Class::set_parent_vfunc_callback() and
Goocanvas::Item_Class::set_canvas_vfunc_callback() are not called.

In a user-defined class derived from Goocanvas::Rect it would be
pointless to override any of the virtual functions defined in
Goocanvas::Item, because these virtual functions are never called.

Is this a general fault in the C++ language binding, or have I gone
astray among the class and object initialization functions? Or is this
behavior by design?