GLib/GObject+C as the lingua franca?

[nf2]

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 
simplistic) style.

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 
pace?

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 
type system,...

>   
>> 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?

Regards,
Norbert