Как мы только что выяснили, и Gtk+, и Qt - полный застой и болото по сравнению с уровнем разработки на других платформах (таких как JavaScript и lisp).
Поэтому хотелось бы понять, как спроектировать программу на основе Boehm GC.
Сначала, понятное дело, нужно
emerge dev-libs/boehm-gc
[ebuild R ] dev-libs/boehm-gc-7.6.4::gentoo USE=«cxx threads -static-libs» ABI_X86=«32 (64) (-x32)» 1 095 KiB
## [R] [sabayonlinux.org] dev-libs/boehm-gc-7.6.4|0 [7.6.4|0]
equery files boehm-gc
/usr/include/gc.h
/usr/lib64/libgc.so.1.3.2
Читаем про GC_MALLOC и GC_MALLOC_ATOMIC.
затем копипастим из hello world.
// if the collector is also built with --enable-gc-debug
// #define GC_DEBUG
// let the collector keep track of thread creation
// keep per-thread allocation caches
#define GC_THREADS
#include <gc.h>
int main()
{
int *q = (int *) GC_MALLOC_ATOMIC(sizeof(int));
*q = 42;
return *q;
}
собираем, запускаем, смотрим:
gcc -I/usr/include test.c /usr/lib64/libgc.so -o test
$ ./test
$ echo $?
42
$ GC_PRINT_STATS=true ./test
Grow heap to 64 KiB after 0 bytes allocated
Number of processors = 4
Started 3 mark helper threads
Initiating full world-stop collection!
--> Marking for collection #1 after 0 allocated bytes
GC #1 freed 0 bytes, heap 64 KiB
World-stopped marking took 0 msecs (0 in average)
In-use heap: 0% (0 KiB pointers + 0 KiB other)
0 finalization entries; 0/0 short/long disappearing links alive
0 finalization-ready objects; 0/0 short/long links cleared
Finalize plus initiate sweep took 0 + 0 msecs
Complete collection took 0 msecs
Adding block map for size of 1 granules (16 bytes)
Дальше жалкие потуги на размышления заходят в тупик. Цель - выставить объектную модель для программ на JavaScript/Lisp (там тоже свой другой gc) и Python.
