Re: C++ interface to glib???? (might do one)

[Lars Hallberg <lah micropp se>]

On Thu, Feb 11, 1999 at 02:55:35PM -0600, Havoc Pennington wrote:
> 
> There are wrappers for the G[S]List in Gtk--, and a wrapper for GDate in
> gtk--plot (Gnome CVS).
> 
> However, to suggest why it hasn't been done already, the primary purposes
> of glib are something like:
> - portability
> - compensating from C's limited standard library
> 
> C++ is already not portable if you use any features,

Most envirionment farly alive do have a C++ compiler supporting
classes, inlinefunction, typesafe linking, inheratens, overloading
and most basic templates and tamplate classes (in an fairly standard
way). Exceptions, namespaces, implicit casting and implementation
and instantiation of big templates might be more truble... 

> and the STL covers
> most of glib's functionality (with exceptions, such as GDate). In general
> the STL will be faster and safer than the glib data structures (certainly
> faster than a glib wrapper).

True, but most STL implementations are farly haevy. Big templates are
not handles well by all compilers. Small tamplates, with a pure inline
impementatien caling a more generic implementation is equally light
as expanding that inline call manually in C.

Glib is a live worked at implementation of basic needs that is used and
starts to becom a standard part at least in Linux distrubutions.

That makes it a god fondation for a light wight C++ lib. C++ need not
be more haevy than C, most implementation are, but that mostly becuse
bloaty libs....

If not as fast as well inlined STL it can be equally fast as calling
glib from C and allot safer and cleaner. Any C++ implementation not
relying on huge templates will share farly the same call overhead.

Glib make even more sens in apps that is linking against it anyway...

> Perhaps a partial wrapper, wrapping only those things that make sense to
> use from C++, would be better.

Anything that it make sens calling from C make sens having a nicer more
safe C++ interface to. I may exclude some stuff i don't think make sens
but I guess most vill...

Is the docs on glib in the web up to date? I saw nothing of error handling.
Is a failed malloc a fattal error that aborts, call a signal or throw
an exeption (depending on the underlying libs). In that case i can ignore
the problem to (the classes will of cource be exception safe).

If the functions may return null pointers on errors I will have to
handel that... Guess most answres are in the source....

If anyone more is intrested in this, mail me! I think this can be done
fairly rapid when started. But I don't know exactly when I can start
(sorry).

TIA /Lars

BTW sorry for the broken english....