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

[Mario Motta <mmotta guest net>]

On Mon, 14 Sep 1998, Guillaume Laurent wrote:
>
>Having libs in the 1Mb range is pretty common these days, and it's of
>little concern with dynamic shared libs. There's nothing we can do to
>reduce Gtk-- size (we tried inlining and it made things worse), and
>VDK will probably be bigger than Gtk-- once all the widgets are
>covered.
>
neverthless memory occupation is a useful information about speaking
lib overlay
>> - memory leak due to fragmentation (so common in C++ when heavily
>> use the heap like VDK and gtk-- i understand)
>
>Having memory leaks has nothing to do with memory
>fragmentation. 

i think here you are wrong, is in fact one the subtle memory leak because
any time you alloc/free the heap there a little but not negligeable memory leak
pending on memory paging and how memory allocator lists manage this work.
I can be more precise having a deeper look to kernel docs, i'm sure applies to
dos/win kernel but should be the same on Linux.

>Speaking of which, this excerpt from VDK's 
>documentation made me jump :
>
>            2. No memory freeing and/or deleting is requested, all new'ed objects will be automatically
>            destroyed at application termination (in future releases an interleaved garbage collection
>            will be provided).
>

jump why ? don't believe or never seen?

>> - machine load and others such things.
>
>Lib size has little to do with machine load, and there is nearly zero
>processing in Gtk--.
same as above, usefule information in lib overlays

>
>> >> - how is fast in signal dispatching ? 
>
>We don't care. Really. Signals mostly react to user's actions, and the
>user can't perceive the difference between a 1ms reaction and a 10ms
>one.
could be true in commercial/business programs where the program is always faster
than end-user fingertip but there are many fields (mine for example) where this
is vital., ie: communications, complex graphics, rendering, time consuming
calculations, numerics control and so on. Just think to a analogic/digital
converter device that is capable to signalling more than 2 Khz, if you want
write an analogic/digital simulator you can't think to make it with Perl/Tk
or with any other GUI that can't support such speed.

>Now regarding VDK, and why I really want to convince you that it
>should be rewritten as a set of Gtk-- classes. Consider
>VDKPixmapButton. It's an almost exact duplication of a class I had
>written almost a year ago, Pixmap_Tipped_Button (see my homepage),
>which was one of my first try at Gtk--. I wrote it probably for the
>same reason as you, because I needed the added convenience. Moreover,
>it was much easier for me to write it than for you, because I was
>already using Gtk--.
>
OpenSource is plenty of duplicate code, two such types of pixmapped buttons
is'nt enough a good reason, i guess Tero see things more pragmactically than
you:-)

  >Gtk-- needs more high-level classes like VDKPixmapButton. Not only as

 >an added commodity, but also because they make great code examples.

ok, begin to work !

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