Re: [gtk-list] GTK++ proposal

[Karl Nelson <kenelson ece ucdavis edu>]

In message <19990126043855.17634.qmail@www05.netaddress.usa.net>karlmail@usa.ne
t writes
>After the original GTK toolkit evolved to the GTK+ 
>toolkit, which added object oriented principles to 
>the C language, I feel that now is the right time to 
>go one step further - GTK++ - a C++ version of GTK+. 

There is actually very little to be accomplished by
porting gtk+ to C++.

Earlier replies have pointed out the problems of the
C++ language, so I will skip those.  So lets compare
the differences between a binding for gtk and gtk in
C++.

A binding suffers from
  1 - large objects
  2 - extra function call to mirror effects
  3 - type translation  (string <=> gchar*)
  4 - structure translation ( list<Gtk_Widget> <=> GList )

If you wrote Gtk directly in C++,  you could knock off
3 and 4.  However, any C++ system is going to suffer that
same penalty unless you use only the STD types.  Having seen
the problems with those types, you will likely end up writing
your own string, hash, etc.  At the same time 2 is insignificant.
That cost would be incured if any of your methods are virtual.
You would suffer even more indirection if you use a virtual base
class needed so that you can use MI (perhaps one of the few
C++ features not in gtk+.)

Assuming that you plan to use the gtk+ style mechanism in C++, you will
need to make signals embedded objects.  As embedded objects 
they will need a virtual table, a pointer to data, and a pointer
to the object itself.  Oddly enough this is the exact cost of the
gtk-- signal system and its proxy system.  So assuming that
you code the same signals your objects would be the exact same
size as the gtk-- objects.  This is the cost of any
functor/signal-slot mechanism under C++.   

That leaves you only to try to improve on the mechanisms themselves.
And considering C++ is like 5% slower and is bulkier for
the same code (adding in exception handling and such), it
is unlikely even if you do away with the hash calls and type
system. 

So basically you would end up with a C++ widget set which
is no faster, no smaller, and no more efficent that a good
binding for gtk+. 

>Before I say more, I realise that people are working 
>at creating bindings for C++, and other bindings exist 
>for many other languages as well, however, I believe 
>that many of the bindings created break the original 
>aims of GTK+ - to be a fast, small and efficient 
>toolkit for programming the X Window System. 
>Many bindings created thus far are either extremely 
>criptic, add unrequired code bulk, or are lacking in 
>features found in GTK+. 

We in the gtk-- group would welcome any input as to
how to improve the bindings.  As for the bulk, that
is a natural effect of C++.  Language features cost,
and so to use C++ you must pay.

> [Snip]
> Perhaps the Gtk-- and VDK authors could 
>chip in too! 

You are welcome to take any part of Gtk--.  But
first I would recommend you look over what exists.  

I would recommend any further discussion of this 
be moved to the Gtk-- maillist.

--Karl 
  Contributor to Gtk--