After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 116280 - Glib::ObjectBase don't inherit SigC::Object virtually
Glib::ObjectBase don't inherit SigC::Object virtually
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: general
2.4
Other other
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2003-06-29 18:52 UTC by Frank Naumann
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Frank Naumann 2003-06-29 18:52:27 UTC
Glib::ObjectBase don't inherit SigC::Object virtually and so also all Gtk
derived classes. But this avoid use of the following C++ technique:

class myclass : virtual public SigC::Object
{
   ... some things that require libsigc++ ...

protected:
   void do_something(void) { ... }
};

class mywidget : public Gtk::Window, public myclass
{
   Gtk::Button button;

public:
   mywidget(void)
   : button("test")
   {
      add(button);
      show_all_children();
      
      button.signal_clicked().connect(
         SigC::slot(*this, mywidget::do_something));
   }
};

At least gcc 3.2.x and above are not able to compile this. They fail in the
libsigc++ template instantiation on the button connect and the compiler
complain that SigC::Object is ambigous (as it's not virtually inherited by
the Gtk/Glib classes). gcc 2.95.x is happy with the one virtual
SigC::Object in myclass declaration.

Just adding the missing virtual to Glib::ObjectBase fix this problem.
Comment 1 Murray Cumming 2003-06-30 08:06:14 UTC
virtual inheritance is complicated. I thought that, if a base class
was virtual then all inheritance was then virtual - and SigC::Object
inherits virtually from something. But I have had the same "ambiguous"
problem with Bakery.

> Just adding the missing virtual to Glib::ObjectBase fix this problem.
Have you actually tested it?
Comment 2 Frank Naumann 2003-06-30 09:01:54 UTC
>virtual inheritance is complicated.

Complicated in which case?

It just ensure that on multiple inheritance a base class is not
replicated, e.g:

class base { ... };

class foo : public base { ... };
class bar : public base { ... };

class fobar : public foo, public bar { ... };

result in the following inheritance scheme:

  base  base
   |     |
   |     |
  foo   bar
   |     |
   \     /
    \   /
    foobar

but with 'base' as virtual base class:

class foo : virtual public base { ... };
class bar : virtual public base { ... };

     base
    /   \
   /     \
   |     |
  foo   bar
   |     |
   \     /
    \   /
    foobar

This is normally exactly what you want with classes that are good
base classes for lot of other classes (for example SigC::Object).

[reference: Bjarne Stroustrup, The C++ Programming Language, Chapter 15]

>> Just adding the missing virtual to Glib::ObjectBase fix this
>> problem.
>Have you actually tested it?

Yes, I completly compiled gtkmm 2.2.2 with this change (including the
examples). No problems so far and my project compile and works fine
with gcc 3.2.x.

I don't know if this is an ABI incompatible change (maybe it depend on
the compiler). But it's at least an option for 2.4 I think.
Comment 3 Murray Cumming 2003-06-30 11:50:19 UTC
But I said:
"I thought that, if a base class
was virtual then all inheritance was then virtual - and SigC::Object
inherits virtually from something."
Comment 4 Frank Naumann 2003-06-30 13:06:24 UTC
>"I thought that, if a base class was virtual then all inheritance was
>then virtual - and SigC::Object inherits virtually from something."

I don't understand you. If a base class is inherited virtual (as I
suggested for SigC::Object) the compiler don't replicate the base
class on multiple inheritance [of the same base class]. That's all.
Comment 5 Murray Cumming 2003-09-18 10:01:26 UTC
I'd like to make this change in gtkmm 2.4.
Comment 6 Frank Naumann 2003-09-18 10:54:27 UTC
That would be nice. I already tried it out and it worked perfectly fine.
Comment 7 Murray Cumming 2003-09-30 12:01:34 UTC
I'm still not convinced that this is not a compiler bug, but I have
committed this to glibmm 2.4 cvs. I have mentioned this bug in a
comment in the code.