Средства и методы разработки

Как я понял -- ищет в памяти похожее на указатели и, соответственно, принимает решение... How does this handle XOR-packed linked lists? If a pointer is XORed, the GC will fail to recognize it, but that's a problem that cannot be solved in any type of GC without extensive support from the language. (C) google. Короче, это просто НЕ РАБОТАЕТ в реальном мире. А на счёт language support совершенно верно. Без этого GC не сделаешь, поэтому для C, C++ и т.п. проще без GC. И часто лучше, ибо GC не гарантирует и возможны дикие memory leaks на некоторых алгоритмах.

Can't a devious C programmer break the collector? Certainly, but most people have better ways to spend their time than dreaming up ways to break their tools. The collector does rely on being able to locate copies of pointers somewhere in an address space, so certain things won't work. For instance, the XOR'd pointers trick for compactly encoding a bidirectional list cannot be used -- the pointers don't look like pointers. If a process writes pointers to a file, and reads them back again, the memory referenced by those pointers may have been recycled. Most programs don't do these things, so most programs work with a garbage collector. Ordinary (legal) pointer arithmetic is tolerated by garbage collectors for C. One problem described by a team considering the use of GC is the use of pointer mangling to get "really opaque" pointers. That is, pointers handed out from a package to a client are XORed with a random number chosen at program start time, and thus the client cannot access package data structures without going through defined interfaces. This is simply incompatible with conservative GC. It is also incompatible with a strict interpretation of the Ansi C standard, and can confuse leak detection tools (which use conservative GC technology to detect leaks), but nonetheless people do it, and it generally does work.

Не работает. От себя добавлю, из реального проекта для МК (дада, ламир, новичок и недоучка, профессионалы всё то же самое делают в 35 простых инструкций): #define malloc(size) __malloc((size)) #define MAGIC1 0xDEAD #define MAGIC2 0xBEEF /* align size, not pointer! */ #define ALIGN(expr, type) (((expr)+(sizeof(type)-1))&~(sizeof(type)-1)) #define MAX_SIZE (SIZE_MAX-sizeof(struct s_low)+2*sizeof(int)) struct s_low { size_t size; unsigned magic1; uintmax_t data[]; }; /* return size in (int) units */ static /*inline*/ size_t size_ints(size_t size) { return ALIGN(sizeof(struct s_low)+size+sizeof(int), int) / sizeof(int); } /* allocate size bytes and place magic numbers around allocated block */ static void *allocate(size_t size) { struct s_low *p; int *v; size_t ints; void *retval; if (size > MAX_SIZE) return NULL; ints=size_ints(size); p=malloc(ints * sizeof(int)); if (p==NULL) return NULL; p->magic1=MAGIC1; p->size=ALIGN(size, int)/sizeof(int); v=(int*)p->data + p->size; *v=MAGIC2; retval=p->data; #ifdef TEST_DMALLOC check(retval); #endif return retval; } void *__malloc(size_t size) { return allocate(size); } В Boehm GC это всё проглючит сразу, т.к. он сразу же высвободит выделенную память.