Re: (glibmm) Deeper level of inheritance in own type of objects - how-to or plans to implement?

[Armin Burgmeier <armin arbur net>]

On Wed, 2008-11-26 at 03:00 +0200, Cristi P wrote:
> I struggled some time ago with doing object inheritance at more than
> one level, like:
> Glib::Object -> MyObjectA (w/ some properties for example) ->
> MyObjectB (w/ additional properties and/or overriden [virtual]
> functions)
> While the gtkmm says about using "inheritance" I couldn't solve the
> problem the way I expect from a C++ library. So, unless I'm mistaken
> somewhere, it *almost* is impossible.
> At that time I did some hard stuff to overcome that problem (with
> implications on how you write your objects) but now I'm getting in
> even bigger problems, when
> instead of starting from Glib::Object I start from some other C++
> wrapper, like, for example,
> Clutter::Group -> MyObjectA -> MyObjectB
> 
> This is really annoying since I want to use C++ w/ the various
> wrappers in more then a simplistic GUI wrapper and with one level of
> inheritance  :-(
> 
> So far the problems that I think I saw:
> a) it seems that the glibmm::object* source files (or at least some
> ObjectBase constructors) are assuming derived objects are mostly C++
> wrappers or one level deeper
> b) (from memory) saw some strange things about declaring the wrapper's
> type as being the C actual type instead of the just created type ?
>    I think there was also a comment like "allow g_peek_class..." to
> work !?
> c) wrappers around methods want to "peek" at the original C object to
> call some functions for example, and are assuming current object has
> its parent type the C object, which, in case it runs on
> object MyObjectB, it is a wrong assumption.

I don't really understand what your problem is. Could you be more
specific on what the actual problem is when you have a Glib::Object -> A
-> B inheritance tree? And maybe provide a compilable test case?

Maybe you need to create an own GType for each of your derived classes.
This can be accomplished by calling the Glib::ObjectBase constructor
with the type name as a string. But this is only a guess.

>   Can't the wrapping code gkmmproc is building,  try, since it really
> knows (or could) the C type, work directly on that type (w/
> g_peek_class...) instead of relying on the
>   actual object instance type being derived directly from the C type?
> d) I also saw some comments about skiping some virtual function calls.
>       I wonder:
>      1) what's the optimization they're talking about? (haven't
> checked sources enough)

When a C++ wrapper is created, such as Gtk::Window, and a C virtual
function is called on the underlying GObject, such as the default signal
handler for the "show" signal, then we can skip calling the virtual
on_show() member function of the C++ object, because it cannot be
overriden anyway.

However, if the same (C) virtual function is called on an instance of a
derived class, such as ExampleWindow inheriting from Gtk::Window, then
ExampleWindow could have overriden the on_show() (C++) virtual function,
so we need to call it.

>      2) (would have to check) - can they also be a source of problems
> for the thing I want to have fixed?

I don't think so.

> Anyway, I might be mistaken, and if there is a method to accomplish
> what I said in the beginning that I want, I'd be glad to hear it!
> 
> Thanks.

Armin