GLib/GObject+C as the lingua franca?
nf2 at scheinwelt.at
Sun Jul 27 01:37:37 BST 2008
Aaron J. Seigo wrote:
> On Friday 25 July 2008, nf2 wrote:
>> I wonder if a kind of mixed style would work: libraries with public
>> GObject/C APIs, but internally stdc++.
> the phrase "disgustingly ugly" comes to mind.
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
Btw, another reason why GLib/GObject might be more suitable than Qt for
the basic platform stuff is simply that it's moving slowly (actually it
will stay as is for long, almost like winapi). The point i'm trying to
make is that what's good for the higher layers (GUI, desktop and apps) -
where Qt seems to fit perfect, might not be ideal further below.
Let's take the KDE desktop environment as an example: Because it's all
monolithic Qt/C++ the whole infrastructure had to be ported from Qt3 to
Qt4 as well. So when you run a KDE3 app on KDE4 you actually have two
desktop environments running (with all the daemons etc). Good? Or
wouldn't it be better if "the platform" could move at a slower/different
Just like coding Nautilus in plain C seems a bit baroque, writing things
like KIO on top of a UI-Toolkit wasn't perfect either IMHO.
>> (AFAIK lot's of them
>> can be auto-generated), C is still the lowest common denominator,
> a lowest common denominator, besides implying it's the least worst thing
> everyone can agree to, only matters if there is buy in from others. i honestly
> don't see that at this point.
Well - for a long time plain C has been the lowest common denominator
(and in rare cases C++). With no main-loop integretion, no signals, no
>> abstract interfaces can be modeled with GInterfaces easily (like GIO
>> does a lot) ...
> the same can be done with other frameworks. glib isn't magical in this regard.
Yeah - but which one would you suggest?
More information about the kde-core-devel