Re: [gtk-list] Re: announce: yet another gtk+ C++ wrapper (no caps as Owen suggest)
- From: Mario Motta <mmotta guest net>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: announce: yet another gtk+ C++ wrapper (no caps as Owen suggest)
- Date: Mon, 14 Sep 1998 22:17:05 +0200
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
neverthless memory occupation is a useful information about speaking
>> - 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
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
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
>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.
AI Research Group - Rimini
] [Thread Prev