13.10.2 Контейнеры и удаление.

   


Назад  |  Вперёд

Допустим, что у нас нет бесконечной памяти и сборщика мусора. На какие средства управления памятью может рассчитывать создатель контейнера, например, класса Vector? Для случая таких простых элементов, как int, очевидно, надо просто копировать их в контейнер. Столь же очевидно, что для других типов, таких, как абстрактный класс Shape, в контейнере следует хранить указатель. Создатель библиотеки должен предусмотреть оба варианта. Приведем набросок очевидного решения:

           template<class T> Vector {
              T* p;
              int sz;
           public:
              Vector(int s) { p = new T[sz=s]; }
              // ...
           };

Если пользователь не будет заносить в контейнер вместо указателей на объекты сами объекты типа Shape, то это решение подходит для обоих вариантов.

           Vector<Shape*> vsp(200);  // нормально
           Vector<Shape> vs(200);    // ошибка при трансляции

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

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

           void f()
                // противоречивое использование средств
                // управления памятью
           {
             Vector<Shape*> v(10);
             Circle* cp = new Circle;
             v[0] = cp;
             v[1] = new Triangle;
             Square s;
             v[2] = &s;
             delete cp; // не удаляет объекты, на которые настроены
                        // указатели, находящиеся в контейнере
           }

Если использовать реализацию класса Vector из $$1.4.3, объект Triangle в этом примере навсегда останется в подвешенном состоянии (на него нет указателей), если только нет сборщика мусора. Главное в управлении памятью это - это корректность. Рассмотрим такой пример:

           void g()
           // корректное использование средств управления памятью
           {
             Vector<Shape*> v(10);
             Circle* cp = new Circle;
             v[0] = cp;
             v[1] = new Triangle;
             Square s;
             v[2] = &s;
             delete cp;
             delete v[1];
           }

Рассмотрим теперь такой векторный класс,который следит за удалением занесенных в него указателей:

           template<class T> MVector {
             T* p;
             int sz;
           public:
             MVector(int s);
             ~MVector();
             // ...
           };

           template<class T> MVector<T>::MVector(int s)
           {
             // проверка s
             p = new T[sz=s];
             for (int i = 0; i<s; i++) p[i] = 0;
           }

           template<class T> MVector<T>::~MVector()
           {
             for (int i = 0; i<s; i++) delete p[i];
             delete p;
           }

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

           void h()
           // корректное использование средств управления памятью
           {
             MVector<Shape*> v(10);
             Circle* cp = new circle();
             v[0] = cp;
             v[1] = new Triangle;
             Square s;
             v[2] = &s;
             v[2] = 0;  // предотвращает удаление s

             // все оставшиеся указатели
             // автоматически удаляются при выходе
           }

Естественно, такое решение годится только для контейнеров, в которых не содержатся копии объектов, а для класса Map ($$8.8), например, оно не годится. Здесь приведен простой вариант деструктора для MVector, но содержится ошибка, поскольку один и тот же указатель, дважды занесенный в контейнер, будет удаляться тоже два раза.

Построение и уничтожение таких контейнеров, которые следят за удалением содержащихся в них объектах, довольно дорогостоящая операция. Копирование же этих контейнеров следует запретить или, по крайней мере, сильно ограничить (действительно, кто будет отвечать за удаление контейнер или его копия?):

           template<class T> MVector {
              // ...
           private:
              MVector(const MVector&); //предотвращает копирование
              MVector& operator=(const MVector&); //то же самое
              // ...
           };

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

Часто бывает полезно уменьшить число указателей, за которыми должен следить пользователь. Действительно, намного проще следить за 100 объектами первого уровня, которые, в свою очередь, управляют 1000 объектов нулевого уровня, чем непосредственно работать с 1100 объектами. Собственно, приведенные в этом разделе приемы, как и другие приемы, используемые для управления памятью, сводятся к стандартизации и универсализации за счет применения конструкторов и деструкторов. Это позволяет свести задачу управления памятью для практически невообразимого числа объектов, скажем 100 000, до вполне управляемого числа, скажем 100.

Можно ли таким образом определить класс контейнера, чтобы программист, создающий объект типа контейнера, мог выбрать стратегию управления памятью из нескольких возможных, хотя определен контейнер только одного типа? Если это возможно, то будет ли оправдано? На второй вопрос ответ положительный, поскольку большинство функций в системе вообще не должны заботиться о распределении памяти. Существование же нескольких разных типов для каждого контейнерного класса является для пользователя ненужным усложнением. В библиотеке должен быть или один вид контейнеров (Vector или MVector), или же оба, но представленные как варианты одного типа, например:

           template<class T> PVector {
              T** p;
              int sz;
              int managed;
           public:
              PVector(int s, int managed = 0 );
              ~PVector();
              // ...
           };

           template<class T> PVector<T>::PVector(int s, int m)
           {
             // проверка s
             p = new T*[sz=s];
             if (managed = m)
                for (int i = 0; i<s; i++) p[i] = 0;
           }

           template<class T> PVector<T>::~PVector()
           {
             if (managed) {
                for (int i = 0; i<s; i++) delete p[i];
             }
             delete p;
           }

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

           template<class T>
           class Handle {
              T* rep;
              int* pcount;
           public:
              T* operator->() { return rep; }

              Handle(const T* pp)
                : rep(pp), pcount(new int) { (*pcount) = 0; }
              Handle(const Handle& r)
                : rep(r.rep), pcount(r.count) { (*pcount)++; }

              void bind(const Handle& r)
              {
                if (rep == r.rep) return;
                if (--(*pcount) == 0) { delete rep; delete pcount; }
                rep = r.rep;
                pcount = r.pcount;
                (*pcount)++;
              }

              Handle& operator=(const Handle& r)
              {
                bind(r);
                return *this;
              }

              ~Handle()
              {
                if (--(*pcount) == 0) { delete rep; delete pcount; }
              }
           };

Назад  |  Вперёд


OtDiatlovaOU
К началу книги

Оформление и дизайн книги OtDiatlovaOU.
Вся книга, архив.

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

Rambler's Top100
Hosted by uCoz