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

[Stefan Teleman]

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.
Hint: C++ generates a whole bunch of symbols which have no place in C
in the first place.

 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.

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 ?

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.

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 ?

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

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

--Stefan

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