Native GTK bindings v2
Artur Skawina
art.08.09 at gmail.com
Sat Apr 21 05:26:59 PDT 2012
On 04/21/12 12:24, Marco Leise wrote:
> At first I confused your project with GtkD. I'll take a look at it, to see how it compares. Many examples for Gtk use C code, and I end up looking for the correct GtkD class that offers the function. Otherwise I quite like the classical inheritance that is possible with GtkD, whereas you use the "alias this" trick, which is fair enough. Also you can bind events like onExpose naturally to class methods in GtkD. There is no data pointer involved.
Hmm, some sugar is likely possible for things like signal callbacks;
i'll think about it.
> On the other hand small executables are my cup of tea. I've compiled a small Haskell Gtk application, that weighted ~10 MB (stripped) and the same program in D using GtkD was 3.4 MB in size. Let's see...
>
"example_gtk", which is probably the smallest /useful/ GTK2 app is 315K
here (32-bit x86 linux), after commenting out the _dumpObj(event) call.
(I wonder how large an equivalent gtkD version would be... But, as i care
more about /runtime/ efficiency, it's not a very interesting metric)
If you care about executable sizes, some GDC specific notes:
- compile with "-ffunction-sections -fdata-sections -Wl,--gc-sections"
Things like std.bitmanip unconditionally emit functions, which will
be rarely used, but bloat the executable.
- do *not* compile with "-Wl,--export-dynamic"
This option will slow down linking, while enabling better backtraces;
unfortunately it will also prevent the gc-sections optimizations above
from working.
- use '-frelease -fno-bounds-check'
- use '-flto'
- do not use '-g' together with '-flto' for the final executable linking
GCC (4.6) bug, can result in ICE.
- strip the executable
artur
More information about the Digitalmars-d-announce
mailing list