сборщик мусора boehm-а

[noch]

Кто ни-будь кто лучше меня знает Си попытается перевести header-ы для использования сборщика с fpc?

<a href='http://www.hpl.hp.com/personal/Hans_Boehm/gc/' target='_blank'>http://www.hpl.hp.com/personal/Hans_Boehm/gc/</a>

Этот сборщик на мой взгляд самый зарекомендовавший себя из всех.

[Sniper]

нужно юзать утилу h2pas из комплекта к FPC

[PVOzerski]

и еще переписывать менеджер памяти для FPC. Это не означает, по счастью, переделку RTL, хватит SetMemoryManager. Но забывать об этом нельзя.

[Romtek]

Об этом можно почитать здесь: <a href='http://community.freepascal.org:10000/bboards/message?message_id=115034&forum_id=24088' target='_blank'> garbage collector.</a>

[Иван Шихалев]

А нафига, собственно?

[noch]

Затем что все мы люди и нам свойственно ошибаться
Поэтому мы используем паскаль с жесткой типизацией.
Еще поэтому мы определяем переменные в секции var чтобы потом если ошибемся в их написании, компилятор сообщил об ошибке а не решил что это новая переменная с значением ноль как бейсик.
Если есть возможность прикрутить мусорщика то это здорово.

Спасибно за ссылки

[STAKANOV]

Как я понимаю из описания у него те же функции что и у стандартного модуля <a href='http://freepascal.ru/wiki/index.php/Category:Heaptrc' target='_blank'>heaptrc</a>

[noch]

Не только, это библиотека, которую можно подключить к своим исходникам и заменить все маллок на его вызов, а о освобождении можно забыть

Память точно будет освобождена

[STAKANOV]

Не только, это библиотека, которую можно подключить к своим исходникам и заменить все маллок на его вызов, а о освобождении можно забыть

Память точно будет освобождена

вот только fpc не использует malloc

[PVOzerski]

Хуже того, malloc не используется и в неявных выделениях блоков памяти при работе, например, с длинными стрками и динамическими массивами. И в операторе new тоже. Отсюда - необходимость замены всего менеджера памяти.

[STAKANOV]

Хуже того, malloc не используется и в неявных выделениях блоков памяти при работе, например, с длинными стрками и динамическими массивами. И в операторе new тоже. Отсюда - необходимость замены всего менеджера памяти.

Спорный вопос. Паскалевский механизм выделения памяти считается более быстрым. Как я понимаю он принципиально такой. И такой же механизм был и у продуктов Borland (TP, Delphi). При запуске процесса ему система выделяет память для кучи, и менеджер памяти уже использует эту область памяти для размещения там данных. Размер кучи фиксирован на протяжении всего времени работы процесса. В принципе последнее это всетаки недостаток. Но если это всетаки критично, то можно использовать системнозависимые вызовы (для юникосв это mmap и shmget).

[PVOzerski]

У меня нет впечатления, что размер кучи неизменен. Я до сих пор думал (и пока еще думаю), что опциями компиляции можно управлять только ее начальным размером, а вот дальше по мере необходимости она может наращиваться. По крайней мере, в виндовом порте это сейчас (или недавно было?) реализовано через HeapAlloc и HeapRealloc.