Прочел об интересном трюке - хранении указателей для двусвязного списка с помощью XOR. Практичность этого трюка сомнительна, разве что в embedded, я бы сам никогда, наверное, не стал им пользоваться. Но идея красивая.
Ну, такой сборщик обломать нетрудно. На C чего только не бывает. Но я так понимаю, если с таким сборщиком вязаться, то надо все делать в его терминах, так что никаких подобных вольностей не допускается.
На самом деле boehm gc неплохо работает в средах, где используется изрядное количество библиотек общего назначения, написанных без расчёта на GC. То есть вольности такого рода изрядно редки. Например, про трюк с int* oneBasedArray = malloc(sz)-1; я читал в связи с мусорными проблемами несколько раз, но в жизни опять же не видел.
Это мне напоминает задачу, с которой я недавно развлекался — разодрать DLL-ку на сегменты кода и данных, чтобы их можно было линковать по отдельности. Делается это исходя из того, в какой сегмент «приземляется» base relocation; теоретически никто не обещал, что такое сработает, и руками довольно легко этот метод обломать. Тем не менее, на существующих в дикой природе DLL проблем не возникает.
int* oneBasedArray = malloc(sz)-1 - за такое надо руки выдергивать :) Его ж потом освободить нормально невозможно, если не помнить везде, что с ним сделали. Но код, который арифметически вычисляет указатели из набора чисел у меня есть. Правда, memory management там не очень нужен.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
Это мне напоминает задачу, с которой я недавно развлекался — разодрать DLL-ку на сегменты кода и данных, чтобы их можно было линковать по отдельности. Делается это исходя из того, в какой сегмент «приземляется» base relocation; теоретически никто не обещал, что такое сработает, и руками довольно легко этот метод обломать. Тем не менее, на существующих в дикой природе DLL проблем не возникает.
вдогонку
no subject