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

[Karl Nelson <kenelson ece ucdavis edu>]

> 
> Hi,
> 
> I made an experimental C++ wrapper called Sugar over the holidays.
> This is a trivial, lightweight, all-inline wrapper (just a header
> file). It replaces the C-style really long names with this sort of
> thing:
> 
>   Window w(Window::TOPLEVEL);
>   Button b("Hello World");
>   b.connect("clicked", (SignalFunc)clicked_cb, NULL);
>   w.add(b);
>   w.show_all();
> 
> But that's pretty much the only feature it has. There's no attempt to
> be a full-featured C++ toolkit.

I think there are at least 3 such wrappers out there like that already.

  ObjGTK - http://www.rit.edu/~waw0573/soft.html#objgtk
  SDPGTK - http://www.k-3d.com/
  (and one other I can't find right now.)

But all suffer the same problems.  Fully inline code results
in very large binaries when used is mess.  (Gtk-- can do it with
some switchs to the code generator, it is really, really bad.)
They don't address the object creation deletion problem
at all.  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.)

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

   Window w(GTK_WINDOW_TOPLEVEL);
   Button b("Hello World");
   b.clicked.connect(slot(&clicked_cb));
   w.add(b);
   w.show_all();

(Enums are still in planning stage, but will not make next stable because
we just froze.)

The cost of such a suger wrapper to solve these problems is it would
be gtk--.  The most recent test of gtk-- development version it cost only 75
bytes over a gtk+ object total (including wrapper (~48), external data,
and associate gtk+ linkages.)   For most of the gtk+ examples (small
programs = worst case) the size is quite reasonable.  

Case study Packer
================= 
(gcc 2.95.2 used on debian potato)
gtk+
  binary size: (gcc compiled)
    unstripped:  144563
    stripped:     15744
  run size:
    size:          1908k
    resident:       477k
    shared:        1556k

gtk--
  binary size: (g++ compiled)
    unstripped:  104274
    stripped:     80432  (C++ carries extra baggage)
  run size:
    size:          3020k (58%) 
    resident:       755k (58%)
    shared:        2368k (52%)

(Note: latest cvs was used.  Results with fault egcs and gtk-- 1.0.2
are 1000% larger)
=================

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?

--Karl