Re: (glibmm) Deeper level of inheritance in own type of objects - how-to or plans to implement?
- From: Armin Burgmeier <armin arbur net>
- To: Cristi P <cristi posoiu gmail com>
- Cc: gtkmm-list gnome org
- Subject: Re: (glibmm) Deeper level of inheritance in own type of objects - how-to or plans to implement?
- Date: Wed, 26 Nov 2008 12:06:07 +0100
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]
> 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
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!
] [Thread Prev