Сборка мусора

[Vitamin]

Это не годится для динамических связных структур данных.

Вот, кстати, ещё один аргумент за сборщик мусора - что лучше: в каждой программе иметь (рекурсивные) процедуры для уничтожения связных структур данных, или иметь один сборщик мусора?

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

Ещё раз: мусор, образовавшийся в одном блоке, не сможет быть утилизирован в пользу другого блока.

сразу не может. но после последовательности освобождение-выделение вполне может случиться и такая ситуация.

Ничего не боюсь!
Одна куча на всю систему.
Со сборщиком мусора.
Кому не надо, не использует его.

одна куча на всю систему может быть только в нижней памяти. да и то она принадлежит системе. а у каждого процесса своя куча, которая рулится ЛЮБЫМ менеджером. по умолчанию- системным (без сборщика)

На какую тему?
Сборщик мусора встаёт поперёк дороги каким-то приёмам оптимизации?

в нашем случае, стандартный менеджер памяти (без сборщика) встал поперек дороги твоему менеджеру со сборщиком. хотя это не так

Можно спроектировать такой интерфейс распределителя памяти, при котором он одновременно записывает адрес в память и загружает в HL. Тогда этот клочок кода превратится в

LD HL,block1
CALL allocate
LD DE,dest
LD BC,len
LDIR

Весьма симпатично.

Возможны также реализации, при которых просматриваться будут указатели только на живые блоки.

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

Существуют также ситуации, при которых со сборщиком мусора будет быстрей. Например, если памяти хватило на всё, то можно не тратить время на освобождение. Образуется мусор, который "на досуге" уберём.

а насколько ты думаешь будет использоваться "куча" программистами, которые до этого с ней никак не работали? довольно большая часть методов, требующих динамическую память, прекрасно решаются в статической