    Для удаления объекта из контейнера в программе выполняется следующий оператор: 

    cp->Detach( 2, TShouldDelete::Delete); 

    Аргумент 2 означает, что третий объект должен быть удален из контейнера. 
Другие объекты сдвигаются вверх для уплотнения освобожденного объектом места. 
Аргумент TShouldDelete::Delete задает, что этот объект должен быть уничтожен 
независимо от статуса владения. 
    Можно также задать, чтобы объект не уничтожался вне зависимости от статуса 
владения. Например, необходимо удалить локальный строковый объект из 
контейнера таким образом: 

    cp->Detach(&s,  TShouldDelete::NoDelete); 

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

    cp->Flush(); 

    При вызове функции Flush() удаляются все объекты, которыми владеет 
контейнер. Для предотвращения сброса вашего кода в "канализацию" в случае, 
если контейнер адресует локальные объекты, следует или отменить владение 
объектами, или заблаговременно удалить такие объекты из контейнера. 
    Можно сделать и так, чтобы объекты удалялись при условии, что контейнер 
владеет ими. Например, в программе можно удалить последний объект, 
индексированный целым п следующим образом:

    cp->Detach(n-1, TShouldDelete::DefDelete); 

    Передача функции Detach параметра DefDelete указывает функции, что 
необходимо уничтожать объект при удалении только тогда, когда контейнер 
владеет им. Если контейнер не владеет своими объектами, оператор удалит из 
него объект, но не освободит занимаемую этим объектом память. 
    Наконец, в примере программы уничтожается контейнер, память для которого 
выделялась в свое время с помощью оператора new: 

    delete cp; 

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

    1. Вызвать функцию Flush() перед удалением контейнера. 
    2. Вывести новый контейнерный класс и написать к нему деструктор, который 
вызывает функцию Flush(). 

    Первое решение, с успехом примененное в примере программы, самое простое, 
но если вы забудете вызвать функцию Flush(), в вашей программе может 
образоваться неприятная утечка памяти. Второе решение гарантирует уничтожение 
динамического контейнера с предварительным вызовом функции Flush(). Для 
реализации последнего объявите новый шаблон класса в модуле OWNER.CPP: 

    template <class T> class TIMyArrayAsVector : 
         public TIArrayAsVector<T> { 
    public: 
       TIMyArrayAsVector(int upper,   int lower = 0,   int delta = 0)  : 
         TIArrayAsVector<T>(upper,  lower,  delta)  { } 
       ~TImyArrayAsVector  { Flush();  }
     };

    В шаблоне класса TIMyArrayAsVector вызывается конструктор его предка. 
Деструктор вызывает функцию Flush() с аргументом по умолчанию DefDelete. 
Контейнер, созданный из этого класса, автоматически уничтожает принадлежащие 
ему объекты, когда контейнер уничтожается или выходит из области видимости. 
    Если вы внесли предыдущие изменения в модуль OWNER.CPP, перепишите алиас 
typedef для TContainer так, как приведено ниже. Теперь в модифицированной 
программе будет использоваться новый производный класс. 

    typedef TIMyArrayAsVector<string> TContainer;        

   
    СОВЕТ

    Ввод производного класса в программу часто требует модификации всех 
прежних употреблений класса-предка. Однако с помощью алнаса, подобного 
TContainer, можно модифицировать программу так, что6ы в ней использовался 
новый класс, изменяв всего лишь одно объявление typedef. Следует представлять 
себе алиасы typedef как константы типов данных. Ими можно пользоваться точно 
так же, как и другими константами, для упрощения поддержки программы. 
    

    436	Часть IV. Разработка приложений 
