C++: библиотека программиста

 
255 
сталкиваемся со знакомой проблемой имитации указателей — раздражающей, но безвредной. Каждый 
раз, когда будет найдено значение, соответствующее адресу некоторого объекта, этот объект 
помечается и включается в рекурсию. 
Внешние объекты 
При управлении несколькими пространствами памяти можно встретить объекты, находящиеся не в 
главном пространстве, в котором происходит сборка мусора, а в другом пространстве по вашему 
выбору. Тот факт, что объект является внешним, не снимает с вас ответственности — он вполне может 
ссылаться обратно, в управляемое пространство. Если это пространство не было рассчитано на 
эффективный перебор указателей (то есть не имеет заголовков объектов), дальше выкручивайтесь 
сами. 
Сборка мусора 
Итак, к концу фазы пометки вы определили доступные объекты. Что же дальше? Без дескрипторов и 
ведущих указателей уплотнение неоправдано, поскольку не существует единого места, в котором 
можно было бы обновить адрес перемещаемого объекта. Теоретически можно сделать второй проход 
по памяти и обновить все указатели тем же способом, который использовался при пометке доступных 
объектов. Прежде чем это делать, закупите побольше акций производителей мощных RISC-
компьютеров: работы у них прибавится. Более практичное решение — организовать сборку мусора на 
месте. 
Если вы не можете гарантировать, что все объекты происходят от общего предак, деструкторы лучше 
не вызывать (а если можете, то зачем использовать такую извращенную и ненадежную архитектуру?). 
Вполне может оказаться, что вы имеет дело с 
int
или 
char*
; никто не гарантирует, что у вашего 
объекта есть v-таблица! Не забывайте о том, что С++ — это все-таки не Lisp и не SmallTalk. 
Последовательная сборка мусора 
Алгоритмы пометки и удаления довольно трудно реализовать в последовательном варианте, но при 
должном внимании возможно и это. К сожалению, подробности выходят за рамки этой книги, но они 
относятся не к С++, а к выбранным вами конкретным алгоритмам. 
Итоговые перспективы 
В двух последних главах я попытался показать, как сделать на С++ то, для чего он не предназначен. В 
методиках управления памятью сочетается все, о чем говорилось в книге, от простейших умных 
указателей и гомоморфизма до объектов классов и подсчета ссылок. Но имеет ли все сказанное какое-
нибудь практическое значение или является высокоинтеллектуальным развлечением? 
Во-первых, лучший способ понять границы возможностей С++ и разобраться в его идиомах — залезть 
в дебри управления памятью. Даже если в ваших проектах это не нужно, хорошее понимание языковых 
ограничений и представления объектов в памяти только пойдет вам на пользу. В конце концов, это 
повысит вашу квалификацию в отладке, поскольку вы будете досконально понимать, как объекты 
хранятся в памяти. 
Во-вторых, в один прекрасный день перед вами может возникнуть задача: организовать серьезное 
управление памятью по промышленным стандартам. Когда эта беда произойдет, вы будете к ней 
готовы. И помните, что эти главы не содержат конкретных решений, а лишь показывают, как 
реализуются на С++ алгоритмы, выкопанные пыли академических изданий. Все описанные приемы 
пригодятся, но мы лишь мимоходом коснулись этой обширной темы. 
В-третьих, представьте себе вечеринку по С++. Вы ждете, когда окружающие придут в хорошее 
расположение духа, берете мартини и произносите ключевую фразу: «Помню, летом 95-го делали мы 
один проект на С++, и возникла задача: реализовать схему сборки мусора с уплотнением…» 
Развлекайтесь! 

---

---