[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: GLib/GObject+C as the lingua franca?
From:       "koos vriezen" <koos.vriezen () gmail ! com>
Date:       2008-07-27 15:49:02
Message-ID: d4e708d60807270849o1a298cfbvaa31c01ca1153828 () mail ! gmail ! com
[Download RAW message or body]

2008/7/27 nf2 <nf2@scheinwelt.at>:

> Why? I think a lot of things that are tiring with plain C - like strings,
> containers and garbage collection might be a bit easier with a bit of C++.
> For instance a simple GObjectWrapper<T> which automatically
> g_object_un_ref's in the destructor - and g_object_refs on copy might help.
> Or a C++ wrapper for GError (that you don't need g_error_free()s all over
> the place)... If someone wants to write a GObject based library in C++,
> perhaps it's worth looking for an appropriate (but still simplistic) style.

I don't think there is that much to gain, whether you do
glib_type_new/g_object_unref vs. new GFoo/delete gfoo. Only you can
create the object on the stack, which saves you the delete call (not
for QObject's though)

Of course this very much depends on the use case. Eg. I maintain a
program both for KDE as for Maemo, and being able to apply patches
easy, I did do some C++ wrapping on simple types as QString and KUrl
(the GUI is completely different anyhow).
A common code pattern might be a class candidate, often a function
will do as well. But doing heavy wrapping in the beginning of the
coding often shows unwanted frictions later, turning to hacks and the
code gets uglier and uglier.
Wrapping toolkits to others is just a pain, Luckily we can use C
directly like glib, expat, libjpeg you-name-it.

Stick with the toolkit API.

Koos
[prev in list] [next in list] [prev in thread] [next in thread]