Re: [gtk-list] Re: ANNOUNCE: Experimental C++ Wrapper

[Havoc Pennington <hp redhat com>]

Executive summary is that some people are right now writing C++
programs with the plain C GTK+ library. I think those people might
like Sugar. 

Karl Nelson <kenelson@ece.ucdavis.edu> writes:
> I think there are at least 3 such wrappers out there like that already.
> 
>   ObjGTK - http://www.rit.edu/~waw0573/soft.html#objgtk

Dead link?

>   SDPGTK - http://www.k-3d.com/

Their primary emphasis seems to be some sort XML deal; but the code is
far more complex than Sugar. 6000 "grep ';'" lines of code, vs. 1400
utterly trivial machine-generated lines for Sugar. Plus it doesn't use
namespaces so you don't save much typing. :-) And I don't understand
why their GtkObject wrapper doesn't do anything with the GtkObject
refcount.

>   (and one other I can't find right now.)

I'm interested if you find it.

> But all suffer the same problems.  Fully inline code results
> in very large binaries when used is mess.

Indeed. The overhead of Sugar would be: 
 - larger binaries (though by God the compiler should 
   be able to optimize 99% of those calls, someone fix it!)
 - assorted ref/unref function calls as Sugar smart pointers
   get created/destroyed/copied
 - 1 pointer per widget (4 bytes on x86 of course), though 
   this pointer is the same pointer you might use in C

You could shrink the binary by de-inlining everything, while keeping
the same API, but that removes the "just a header file, nothing to
install" advantage.

The Sugar code generator script could be changed in an hour or two to
experiment with that. Or the script could output both versions of
Sugar and let app developers choose.

Of course, it's possible that "just a header file" is the only
compelling advantage. Then de-inlining isn't an option and the large
code may be fatal.

A small static lib may be the nicest solution; then you get the
no-libraries-for-users-to-install advantage but your code size isn't
all that bad (one copy of each function you actually use). I like this
idea actually.

> They don't address the object creation deletion problem
> at all.  

What is this problem? Sugar cleanly handles object lifecycle via the
native GtkObject refcount I think.

> Their typesafty is very poor and you must only use
> static callbacks.  (In short, they are less than suger as they
> are only sweet the first time you use them.)
> 

You are comparing to a full-featured C++ wrapper. Sugar is meant to be
more convenient than plain C, not as C++-like as a real C++ toolkit.

To that end it adds _some_ type safety - enough to avoid the endless
GTK_BLAH() casts - but no more. And it does not touch the
callback/signal problem.

i.e. if you've currently chosen to program in C++ but with plain C
GTK+, Sugar might be a nice improvement with no real cost. It's even
nciely interoperable with the plain C stuff so you can migrate slowly.

> Any why rewrite when gtk-- already had the exact same syntax and
> approximately the same size.  
> 

The README lists a number of advantages of a closer-to-C minimalist
approach; I won't repeat them here. I think I like this approach, but
I say the release is experimental because I don't know if anyone else
will like it.
 
> For large programs this overhead drops to arround 26% (~size of
> gtk-- wrapper/gtk+ widget size)  Having battled for 6 months to
> get gtk-- down this small while keeping features which C++
> like, I really don't see the need for "yet another featureless C++
> gtk+ wrapper."  (YAFCGW)
> 
> So why another wrapper of this nature?  How can it be much lighter
> if nothing can be shared?  Why not get one C++ wrapper which is
> suitable for all uses?
> 

Well gtk-- takes the approach of deciding on the minimal feature set
(a complete C++-style interface with all the things C++ programmers
expect) and then trying very, very hard to get that optimized enough
to be acceptable. I think gtk-- does a good job. However, it
invariably and inevitably adds a lot of complexity: things to
document, things to have bugs, stuff to install, code to take up
space, stuff to maintain, and a binding-specific learning curve. For
many programmers this is worth it for the features, witness all the
interest on the gtk-- mailing list!

Sugar is very different; the approach is to say, "how many nice
features can I add without significant complexity or overhead,"
including Sugar and application developer overhead. :-) Thus I can
have a complete (or darn close) wrapper in a few evenings. If people
use it I can add GNOME stuff in another evening or two. I can
experiment with de-inlining the wrapper in just a couple hours. And
there's no way the wrapper can have much in the way of bugs. 

This means a language binding without many tradeoffs compared to the
plain C API (code size being the only one I can think of). It is also
compatible with a minimalist, low-complexity C++ style that many
people use. I don't know how many used it consciously and how many had
broken compilers, time will tell I guess. :-)

Again, the README has more bullet-points on why I think this is
convenient. But also again, it is an experiment to see what people
think. 

In any case I think the people that might like Sugar aren't using
Gtk-- now so there is not a real competition between Sugar and Gtk--.

Havoc