GLib/GObject+C as the lingua franca? (was: kwallet and QCA)

[koos vriezen]

2008/7/25 Stefan Teleman <stefan.teleman at gmail.com>:
> On Fri, Jul 25, 2008 at 4:51 PM, koos vriezen <koos.vriezen at gmail.com> wrote:
>
>>> Yes, and duplicating already existing work -- especially when backed
>>> by the "too many symbols in shared library" argument --  is *always*
>>> the best alternative. Even more so when said existing work does have
>>
>> I don't understand. Why is that argument special?
>
> Because:
>
> 1. The original argument against lib*mm ("there are more symbols in
> the C++ wrapper Library than in the original C Library") is bogus.
> Yes, writing a C++ wrapper around a C library and maintaining the
> original C functionality will end up generating more symbols in the
> C++ library ratio to the original C implementation.

Yes that, but for all those symbols are extra, ie. you don't loose the
C symbols.

> Hint: C++ generates a whole bunch of symbols which have no place in C
> in the first place.

Yes

>  Also, i didn't realize that counting the number of symbols in a
> particular library implementation is a design choice consideration in
> the first place. If the number of symbols was indeed a design choice
> consideration, one could easily make this argument with QT4 vs. QT3.

That was exactly what TT did with Qt4, reduce the number of symbols by
splitting up the library so that an editor don't drag along SQL
symbols, reduce the API in general and enable the visibility-hidden
for internal functions.

> Are there any guidelines for the "number of acceptable symbols" in a
> C++ shared library, other than "i don't like this number" ? Is there a
> C equivalent for these hypothetical guidelines ?

The less the better, I would say ...

> 2. Work has already been done. It works (for any given value of
> "works"). It is used in other apps. Is "existing, reusable code" no
> longer a design consideration ? I thought this is what C++ was
> supposed to be about. But maybe i am old fashioned and i have no kept
> up with the latest and greatest software development trends.

Not using that code is even better, no?

> Other than the "my
> C++-wrapper-API-is-better-than-your-C++-wrapper-API" argument, what is
> the point of creating yet another C++ wrapper around GLib/Gtk+/bla ?

Yes exactly my argument, why wrap?

> I can name off the top of my head two major applications which use the
> lib*mm frameworks: Kino and Inkscape.

And there are many more that run on plain Gtk

> Can you name one app written in Vala, or in the
> "as-of-yet-unwritten-but-gooder-C++-wrapper-around-glib-gtk-atk-pango-cairo"
> ?

But why should we, that's my point. The nice thing about C++ is that
you can use any C library out-of-the-box.

Koos

> --Stefan
>
> --
> Stefan Teleman
> KDE e.V.
> stefan.teleman at gmail.com
>