Re: [gtk-list] Re: announce: yet another gtk+ C++ wrapper (no caps as Owen suggest)

[Mario Motta <mmotta guest net>]

On Sun, 13 Sep 1998, Tero Pulkkinen wrote:
>
>Thin means it uses about the same abstractions as previous layer.
>=> the implementation of it is simple.
>
i agree with this point of view,  moreover  "thins" concerns also:
- memory occupation that can lead into "swap hell".
- memory leak due to fragmentation (so common in C++ when heavily
use the heap like VDK and gtk-- i understand)
- 
machine load and others such things.
>* type safety
>  (signal system, virtual functions, consts, strings, bools have all
>   increased type safety of the interface - there's still some work to
>   do in this area...)
moreover in VDK side all calls coming from gtk+ are type checked using
dynamic rtti thsu should be safe, but you're right much remain to do..
>* C++ syntax for things
>* C++-style memory management
>  This is much better in gtk-- than in many other C++ widget libraries.
>  (the trick is to not move widget ownership to containers - allows
>  storing widgets in stack for example and let C++'s
>  constructors/destructors/scopes handle it properly)
>  (btw, copying widgets is forbidden in gtk--. This isnt however
>  not enforced yet, but absolutely should be!)
VDK side same: copy and assignement between "widgets" are
prohibited (flagged as compile error) unless you disclose to me a safe way to
implement smart pointers :-) 
>> - wich is the code reduction factor ? 
>I believe gtk-- programs are half smaller than similar gtk+ programs.
>(this is because more use of inheritance and virtual functions, instead of
>just using widgets).
>
VDK side: more or less equal roughly 1:3 but are very poor measures, most
depends on writing styles.
 
>> - how is fast in signal dispatching ? 
>
>there's at least 4 different cases:
>3) virtual function calls coming from gtk+ (proxy stuffs -- again 3-4 function
>   calls slower than gtk+'s virtual function call) (this one currently
>   has one hash table lookup, which makes it more expensive)
>
point 3 is most interesting, VDK side:  using a static early binded table
and a plain straight search (can be recursed) not better than teta(N),
i do not guess to do better than unless using trees but there is much overhead
taking in account the overhead of gtk+ calls. Semi trivial bench marks showed
roughly ten thousand signals emitted by gtk+, catched, binded and dispatched
in 1 second, taking in account that the code was fat debugged, off-line inlining
and involved with a virtual call i'm satisfied even if the optimum should be log(N).

>> (if you want i can show you how gtk+ is able to erase and substitute with a
>> GtkWidget* the famous "this" hidden first arg of C++ member call)
>
>hmm... I didnt understand what you mean in this one... 
try something like this:
template <class T>
gint SignalConnect(char* signal, T* object, GtkWidget* widget, 
	void (T::*handler)(T* sender)) 
{
return gtk_signal_connect(GTK_OBJECT(widget),
			signal,
			GTK_SIGNAL_FUNC((object->*handler),
			object);
// this aside my errors (i'm writing from scratch) and a a subtle warning by the
// compiler (provided -Wall) should compile flawless
}
// Assuming that A is a class into widget hierarchy:
//. A constructor
A::A() { 
widget = gtk_some_widget_new(); 
SignalConnect("a_signal",this,widget,&A::MyAnswer);
// assume this = 1000 for instance
// and widget =  2000 for instance
}
//...
and now the class A response method
void A::MyAnswer(A* sender)
{
printf("\n this:%p, sender:%p", this,sender)
fflush(stdout);
// output will be: this:2000, sender: 1000
// gtk+ calls MyAnswer putting (as was easy  to foresee) widget as first hidden
//arg thus replacing this with his own widget. 
}

>
>> Continuing to discuss without those type of information is useless
>> and better to continue to speak philosophically: - is my personal
>> opinion (and i read something about during this thread) that the
>> gtk-- makers were so satisfied with that signal mechanism that
>> stopped to use C++ as C++ and used it only as a better C, that was a
>> short track and made unuseless to do examples and tests mainly
>> because they would have resulted in a gtk+ clones.
>
>The project started from "better C" approach - originally it was just
>direct mapping from C functions to classes and some macros to do the
>functionality of signals. After that, it has been slowly transformed
>to use more C++ style interface and typesafety has been
>increased. This should be still continued and transformed to look even
>more like what gtk+'s interface would have been if it were written in
>C++ originally.
>
>originally there were no additional typesafety compared to gtk+ - but
>it even at that point did implement most of gtk+'s interface.
>
>There's still much to do - many places the gtk+'s interface is
>still visible -- and it should be.
>
>Yup, this kind of wrappers are also needed. Gtk-- is not one of those and
>never tried to be one. Gtk+ does have many widgets and many methods and
>functions. This is fine for low level interfaces like gtk+ and gtk-- are. 
>Higher level library should radically cut down the number of widgets
>and raise abstraction level, cut down amount of functions and types
>programmers need to know.
>
VDK try to be
>(ugh, this is too long again :)
>
no, some tech speach sometime are amusing.

more than friendly
--
Mario Motta
===========
AI Research Group - Rimini
mmotta@guest.net
http://www.guest.net/homepages/mmotta/index.htm