обработки нехватки памяти используется my handler

Этот прием описан в [Stroustrup, 1986] и является обпцш способом обработки ошибок при выделении ресурсов. С помошью обработчика new handler можно:

□ найти дополнительные ресурсы, например свободную память, которую можно выделить;

□ вывести сообшение об ошибке и каким-то способом закончить выполнение программы.

Применение обработки исключений позволяет программе отреагировать на ошибку не столь радикальным способом, как завершение работы (см. раздел 16.5).

10.7. Автоматическая сборка мусора

При проектировании С++ я сознательно решил не полагаться на авто.мати-ческую сборку мусора, опасаясь весьма значительных издержек по времени и памяти, которые удалось наблюдать в различных сборшиках мусора. Также могли возникнуть дополнительные сложности при написании компилятора и переносе его на другие платформы. Кроме того, сборка мусора сделала бы С++ непригодным для многих низкоуровневых задач, ради которых язык создавался.

По-моему, если вам нужна сборка мусора, то вы можете либо сами реализовать некоторую автоматизированную схему управления памятью, либо воспользоваться языком, который поддерживает сборку мусора напрямую, например старым добрым Simula. Сегодня и для реализации, и для переноса имеется больше ресурсов. Существует много програ,мм на С++, которые просто нельзя переписать на других языках. Технология сборки .мусора усовершенствовалась, а многие из тех до.морощенных схем, с которыми я работал, не перешли из отдельных проектов в библиотеки общего назначения. Но более важно то, что с помощью С++ реализуются все более важные проекты. В некоторых из них сборка мусора определенно была бы полезна, а связанные с ней затраты вполне терпимы.

10.7.1. Необязательный сборщик мусора

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

Для выполнения второго требования был введен обработчик new handler -определенная пользователем функция, которая гарантированно вызывалась при невозможности выделить память оператором new. Например:

void my handlего {/*.-.*/}

void f() {

set new handler(&my handler) ; начиная с этого момента для-

Главные причины, по которым наличие сборщика мусора желательно, таковы:

□ сборка мусора упрощает построение и применение некоторых библиотек;

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

Аргументов против несколько больще, но они менее принципиальны, поскольку связаны с реализацией и эффективностью:

□ сборка мусора сопряжена с такими издержками времени и памяти, которые неприемлемы для многих приложений С++, работающих на существующем оборудовании;

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

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

□ некоторые схе.мы сборки мусора несовместимы с несколькими базовыми .ме-ханизма.ми С, например с арифметическими действиями над указателями, массивами без контроля выхода за границу и неконтролируемыми аргументами функций (типа printf);

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

Есть и другие аргументы за и против наличия сборщика мусора. Сравнивая системы, имеющие и не имеющие сборку мусора, следует помнить: не каждая программа должна работать без остановки; не любой код является частью базовой библиотеки; многие программы могут управлять памятью самостоятельно, без сборки мусора и схожих методов типа подсчета ссылок. С++ не нужна сборка мусора, так же как и языку без истинных локальных переменных (см. раздел 2.3). Если для управления па.мятью достаточно более конкретных методов (скажем, специализированных распределителей, см. разделы 10.2, 10.4, 15.3.1, [2nd, §5.5.6, §13.10.3]), а также автоматического и статического хранения (см. раздел 2.4), то можно получить существенный выигрыщ во вре.мени и памяти по сравнению с автоматической сборкой мусора и оператором освобождения памяти.

Общий вывод таков: сборка мусора желательна и возможна, но мы не можем позволить, чтобы от нее была зависима семантика С++ и больщинства стандартных базовых библиотек.

Значит, реальная проблема заключается в том, стоит ли включать необязательный сборщик мусора для С++. Когда (не если !) сборщик мусора станет доступен, мы сможем писать программы на С++ двумя способами. В целом это не сложнее, чем управляться с несколькими библиотеками, поддерживать приложение на разных платформах и т.д. Необходимость делать такой выбор - обычное следствие самой природы языка общего назначения, который к тому же щироко применяется. Бессмысленно требовать одинаковой среды выполнения для головки са.монаводящейся ракеты, персонального компьютера, телефонного коммутатора.

клона UNIX, мейнфрейма IBM, компьютера MAC и т.д. и т.п. Правильно реализованная сборка мусора станет еще одной возможностью при выборе среды выполнения приложения.

Может ли данное средство стать законны.м и полезным, если его не специфицировать в стандарте C-I-+? Видимо, да. Но мы ие можем включить его в стандарт, поскольку не существует схемы, хоть в какой-то .мере пригодной для стандартизации. Экспериментальные данные должны показать, что схема достаточно удобна для широкого круга реальных приложений. Кроме того, у нее не должно быть неустранимых недостатков, которые сделали бы С++ непригодным для применения в каком-либо важном классе приложений. При наличии хотя бы одного успепшо-го экснери.мента разработчики компиляторов рьяно возьмутся за поиск лучпп1х реализаций. Нам остается только надеяться, что они не выберут несовмести.мые между собой схемы.

70.7.2. Как должен выглядеть необязательный сборщик мусора?

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

Лучший вариант, если сборка мусора не используется, - ко.мпилятор со сборщиком .мусора должен создавать такую же эффективную по времени и па.мяти програ,мму, как и компилятор без данного средства. Это легко, если заставить про-гра.м.миста указать, что никакая часть этой програ.ммы не исполызует сборку мусора , по очень трудно, если компилятор должен обеспечить максимальную эффективность за счет адаптирующегося алгоритма сборки мусора.

Наоборот, разработчику сборщика мусора могут потребоваться подсказки со стороны пользователя, чтобы обеспечить приемлемую производительность средства. Например, может потребоваться указание, для каких объектов нужна сборка мусора, а для каких - нет (напри.мер, когда они созданы в написанной на С или Fortran библиотеке, не поддерживающей сборку мусора). Если такие подсказки вообще возможны, то компилятор без сборщика мусора должен их игнорировать. Другое решение - предоставить способ быстро убрать подсказки из исходного текста.

Некоторые операции С++, например устаревшие приведения типов, объединения, состоящие из указателей и не-указателей, арифметические действия над указателями и т.д. плохо сочетаются со сборкой мусора. В удачно написанной С++-программе такие операции встречаются нечасто, поэтому возникает желание вообще запретить их. Таки.м образом, вступают в конфликт две возможности:

□ запретить небезопасные операции, что делает программу надежней, а сборку мусора более эффективной;

□ не запрещать ни одну С++-программу, правильную с точки зрения теку1це-го определения языка;

Думается, что можно найти компромисс и изобрести такую схему сборки мусора, которая подойдет почти для любой корректной С++-программы, а при отсутствии небезопасных операций станет только эффективнее.