ки операции ->, то
преимущество, что теперь можно строить производные
от set_controller классы. Љ сожалению, мы можем потерЯть и некоторые
достоинства управлЯющего класса, если к производным классам будут
добавлЯтьсЯ члены, представлЯющие данные. Њожно сказать, что
программный объем, который разделЯетсЯ между управлЯемыми классами
уменьшаетсЯ по мере роста программного объема управлЯющего класса.


        13.10 “правление памЯтью

Џри проектировании библиотеки или просто программы с большим временем
счета один из ключевых вопросов свЯзан с управлением памЯтью.
‚ общем случае создатель библиотеки не знает, в каком окружении она
будет работать. Ѓудет ли там ресурс памЯти настолько критичен, что ее
нехватка станет серьезной проблемой, или же серьезной помехой станут
накладные расходы, свЯзанные с управлением памЯтью?
   Ћдин из  основных вопросов управлениЯ памЯтью можно сформулировать
так: если функциЯ f() передает или возвращает указатель на объект, то
кто должен уничтожать этот объект?  Ќеобходимо ответить и на свЯзанный
с ним вопрос: в какой момент объект может быть уничтожен? Ћтветы на эти
вопросы особенно важны длЯ создателей и пользователей таких контейнеров,
как списки, массивы и ассоциативные массивы. ‘ точки зрениЯ
создателЯ библиотеки идеальными будут ответы: "‘истема" и "‚ тот момент,
когда объект больше никто не использует". Љогда система уничтожает
объект, обычно говорЯт, что она занимаетсЯ сборкой мусора, а та часть
системы, котораЯ определЯет, что объект больше никем не используетсЯ,
и уничтожает его, называетсЯ сборщиком мусора.
   Љ сожалению, использование сборщика мусора может повлечь за собой
накладные расходы на времЯ счета и памЯть, прерываниЯ полезных
функций, определенную аппаратную поддержку, трудности свЯзываниЯ
частей программы на разных Языках или просто усложнение системы.
Њногие пользователи не могут позволить себе этого.њ

њ ѓоворЯт, что программисты на ‹испе знают, насколько важно управление
памЯтью, и поэтому не могут отдать его пользователю. Џрограммисты
на ‘ тоже знают, насколько важно управление памЯтью, и поэтому не
могут оставить его системе.

Џоэтому в большинстве программ на ‘++ не приходитсЯ рассчитывать
на сборщик мусора и нужно предложить свою стратегию размещениЯ
объектов в свободной памЯти, не обращаЯсь к системе. Ќо реализации
‘++ со сборщиком мусора все-таки существуют.
    ђассмотрим самую простую схему управлениЯ памЯтью длЯ программ
на ‘++. „лЯ этого заменим operator new() на тривиальную функцию
размещениЯ, а operator delete() - на пустую функцию:

        inline size_t align(size_t s)
        /*
           „аже в простой функции размещениЯ нужно
           выравнивание памЯти, чтобы на объект
           можно было настроить указатель
           произвольного типа
        */
        {
          union Word { void* p; long double d; long l; }

          int x = s + sizeof(Word) - 1;
          x -= x%sizeof(Word);
          return x;
        }

        static void* freep; // настроим start на свободную памЯть

        void* operator  new(size_t s) // простаЯ линейнаЯ функциЯ размещениЯ
        {
          void* p = freep;
          s = align(s);
          freep += s;
          return p;
        }

        void operator delete(void*) { }  // пусто

…сли памЯть бесконечна, то наше решение дает сборщик мусора без
всЯких сложностей и накладных расходов. ’акой подход не применим
длЯ библиотек, когда заранее неизвестно, каким образом будет
использоватьсЯ памЯть, и когда программа, пользующаЯсЯ библиотекой,
будет иметь большое времЯ счета. ’акой способ выделениЯ памЯти
идеально подходит длЯ программ, которым требуетсЯ ограниченный объем
памЯти или объем, пропорциональный размеру входного потока данных.

        13.10.1 ‘борщик мусора

‘борку мусора можно рассматривать как моделирование бесконечной
памЯти на памЯти ограниченного размера. ЏомнЯ об этом, можно
ответить на типичный вопрос: должен ли сборщик мусора вызывать
деструктор длЯ тех объектов, памЯть которых он использует? Џравильный
ответ - нет, поскольку, если размещенный в свободной памЯти объект
не был удален, то он не будет и уничтожен. €сходЯ из этого, операцию
delete можно рассматривать как запрос на вызов деструктора (и еще это
- сообщение системе, что памЯть объекта можно использовать). Ќо как
быть, если действительно требуетсЯ уничтожить размещенный в свободной
памЯти объект, который не был удален? ‡аметим, что длЯ
статических и автоматических объектов такой вопрос не встает, -
деструкторы длЯ них неЯвно вызываютсЯ всегда. „алее, уничтожение
объекта "во времЯ сборки мусора" по сути ЯвлЯетсЯ
операцией с непредсказуемым результатом. Ћна может совершитьсЯ
в любое времЯ между последним использованием объекта и "концом
программы"њ, а значит, в каком состоЯнии будет программа в этот момент
неизвестно.

њ ‡десь использованы кавычки, потому что трудно точно определить,
что такое конец программы. (прим. перев.)

’рудно правильно запрограммировать такие операции и они не так полезны,
как кажетсЯ.
   ‡адачу уничтожениЯ объектов, если времЯ этой операции точно не задано,
можно решить с помощью программы обслуживаниЯ заЯвок на уничтожение. Ќазовем
ее сервером заЯвок. …сли объект необходимо уничтожить в конце программы,
то надо записать в глобальный ассоциативный массив его адрес и
указатель на функцию "очистки". …сли объект удален Явной операцией,
заЯвка аннулируетсЯ. Џри уничтожении самого сервера (в конце
программы) вызываютсЯ функции очистки длЯ всех оставшихсЯ заЯвок.
ќто решение подходит и длЯ сборки мусора, поскольку мы рассматриваем
ее как моделирование бесконечной памЯти. „лЯ сборщика мусора нужно
выбрать одно из двух решений: либо удалЯть объект, когда единственной
оставшейсЯ ссылкой на него будет ссылка, находЯщаЯсЯ в массиве самого
сервера, либо (стандартное решение) не удалЯть объект до конца
программы, поскольку все-таки ссылка на него есть.
     ‘ервер заЯвок можно реализовать как ассоциативный массив ($$8.8):

         class Register {
             Map&lt;void*, void (*) (void*)> m;
         public:
             insert(void* po, void(*pf)()) { m[po]=pf; }
             remove(void* po) { m.remove(po); }
         };

         Register cleanup_register;

Љласс, постоЯнно обращающийсЯ к серверу, может выглЯдеть так:

         class X {
           // ...
           static void cleanup(void*);
         public:


          X()
          {
            cleanup_register.insert(this,&amp;cleanup);
            // ...
          }


          ~X() { cleanup(this); }

           // ...
         };

         void X::cleanup(void* pv)
         {
           X* px = (X*)pv;
           cleanup_register.remove(pv);
           // очистка
         }

 —тобы в классе Register не иметь дела с типами, мы использовали
статическую функцию-член с указателем типа void*.

        13.10.2 Љонтейнеры и удаление

„опустим, что у нас нет бесконечной памЯти и сборщика мусора. Ќа какие
средства управлениЯ памЯтью может рассчитывать создатель
контейнера, например, класса Vector? „лЯ случаЯ таких простых элементов,
как int, очевидно, надо просто копировать их в контейнер. ‘толь же
очевидно, что длЯ других типов, таких, как абстрактный класс Shape,
в контейнере следует хранить указатель. ‘оздатель библиотеки
должен предусмотреть оба варианта. Џриведем набросок очевидного
решениЯ:

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

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

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

Љ счастью, транслЯтор отслеживает попытку создать массив объектов
абстрактного базового класса Shape.
   Ћднако, если используютсЯ указатели, создатель библиотеки и
пользователь должны договоритьсЯ, кто будет удалЯть хранимые
в контейнере объекты. ђассмотрим пример:

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

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

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

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

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

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

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

Џользователь может рассчитывать, что содержащиесЯ в MVector указатели
будут удалены. Ћтсюда следует, что после удалениЯ MVector пользователь
не должен обращатьсЯ с помощью указателей к объектам, заносившимсЯ в этот
контейнер. ‚ момент уничтожениЯ MVector в нем не должно быть
указателей на статические или автоматические объекты, например:

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

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

…стественно, такое решение годитсЯ только длЯ контейнеров, в
которых не содержатсЯ копии объектов, а длЯ класса Map ($$8.8),
например, оно не годитсЯ. ‡десь приведен простой вариант деструктора
длЯ MVector, но содержитсЯ ошибка, поскольку один и тот же указатель,
дважды занесенный в контейнер, будет удалЯтьсЯ тоже два раза.
    Џостроение и уничтожение таких контейнеров, которые следЯт
за удалением содержащихсЯ в них объектах, довольно дорогостоЯщаЯ
операциЯ. Љопирование же этих контейнеров следует запретить
или, по крайней мере, сильно ограничить (действительно, кто
будет отвечать за удаление контейнер или его копиЯ?):

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

Ћтсюда следует, что такие контейнеры надо передавать по ссылке
или указателю (если, вообще, это следует делать), но тогда в управлении
памЯтью возникает трудность другого рода.
    —асто бывает полезно уменьшить число указателей, за которыми
должен следить пользователь. „ействительно, намного проще следить
за 100 объектами первого уровнЯ, которые, в свою очередь, управлЯют
1000 объектов нулевого уровнЯ, чем непосредственно работать с
1100 объектами. ‘обственно, приведенные в этом разделе приемы,
как и другие приемы, используемые длЯ управлениЯ памЯтью, сводЯтсЯ
к стандартизации и универсализации за счет применениЯ  конструкторов
и деструкторов. ќто позволЯет свести задачу
управлениЯ памЯтью длЯ практически невообразимого числа объектов,
скажем 100 000, до вполне управлЯемого числа, скажем 100.
  Њожно ли  таким образом определить класс контейнера, чтобы
программист, создающий объект типа контейнера, мог выбрать
стратегию управлениЯ памЯтью из нескольких возможных, хотЯ определен
контейнер только одного типа? …сли это возможно, то будет ли оправдано?
Ќа второй вопрос ответ положительный, поскольку большинство функций
в системе вообще не должны заботитьсЯ о распределении памЯти.
‘уществование же нескольких разных типов длЯ каждого контейнерного
класса ЯвлЯетсЯ длЯ пользователЯ ненужным усложнением. ‚ библиотеке должен
быть или один вид контейнеров (Vector или MVector), или же оба, но
представленные как варианты одного типа, например:

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

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

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

   Џримером класса, который может предложить библиотека длЯ облегчениЯ
управлениЯ памЯтью, ЯвлЯетсЯ управлЯющий класс из $$13.9. ђаз в
управлЯющем классе ведетсЯ подсчет ссылок на него, можно спокойно
передавать объект этого класса, не думаЯ о том, кто будет
удалЯть доступные через него объекты. ќто сделает сам объект управлЯющего
класса. Ќо такой подход требует, чтобы в управлЯемых объектах было поле
длЯ подсчета числа использований. ‚ведЯ дополнительный объект, можно
просто снЯть это жесткое требование:

           template&lt;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&amp; r)
                : rep(r.rep), pcount(r.count) { (*pcount)++; }

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

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

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

        13.10.3 ”ункции размещениЯ и освобождениЯ

‚о всех приведенных примерах памЯть рассматривалась как нечто данное.
Ћднако, обычнаЯ функциЯ общего назначениЯ длЯ распределениЯ свободной
памЯти оказываетсЯ до удивлениЯ менее эффективной, чем функциЯ размещениЯ
специального назначениЯ. ‚ырожденным случаем таких функций можно
считать приведенный пример с размещением в "бесконечной" памЯти и
с пустой функцией освобождениЯ. ‚ библиотеке могут быть более
содержательные функции размещениЯ, и бывает, что с их помощью
удаетсЯ удвоить скорость выполнениЯ программы. Ќо прежде, чем пытатьсЯ
с их помощью оптимизировать программу, запустите длЯ нее профилировщик,
чтобы выЯвить накладные расходы, свЯзанные с выделением памЯти.
   ‚ разделах $$5.5.6 и $$6.7 было показано как с помощью определениЯ
функций X::operator new() и X::operator delete() можно использовать
функцию размещениЯ длЯ объектов класса X. ‡десь есть определеннаЯ
трудность. „лЯ двух классов X и Y функции размещениЯ могут быть
настолько сходными, что желательно иметь одну такую функцию.
€ными словами, желательно иметь в библиотеке такой класс, который
предоставлЯет функции размещениЯ и освобождениЯ, пригодные длЯ размещениЯ
объектов данного класса. …сли такой класс есть, то функции размещениЯ
и освобождениЯ длЯ данного класса получаютсЯ за счет привЯзки к нему
общих функций размещениЯ и освобождениЯ:

           class X {
              static Pool my_pool;
              // ...
           public:
              // ...
             void* operator new(size_t) { return my_pool.alloc(); }
             void operator delete(void* p) { my_pool.free(p); }
           };

           Pool X::my_pool(sizeof(X));

‘ помощью класса Pool памЯть распределЯетсЯ блоками одного размера.
‚ приведенном примере объект my_pool отводит памЯть блоками
размером sizeof(X).
  ‘оставлЯетсЯ описание класса X и используетсЯ Pool с учетом оптимизации
скорости программы и компактности представлениЯ. Ћбратите внимание,
что размер выделЯемых блоков памЯти ЯвлЯетсЯ длЯ класса "встроенным",
поэтому задающий размер параметр функции X::operator new() не
используетсЯ. €спользуетсЯ вариант функции X::operator delete()
без параметра. …сли класс Y ЯвлЯетсЯ производным класса X, и
sizeof(Y)>sizeof(X), то длЯ класса Y должны быть свои функции
размещениЯ и освобождениЯ. Ќаследование функций класса X приведет
к катастрофе. Љ счастью, задать такие функции длЯ Y очень просто.
   Љласс Pool предоставлЯет свЯзанный список элементов требуемого
размера. ќлементы выделЯютсЯ из блока памЯти фиксированного размера
и по мере надобности запрашиваютсЯ новые блоки памЯти. ќлементы
группируютсЯ большими блоками, чтобы минимизировать число обращений
за памЯтью к функции размещениЯ общего назначениЯ. „о тех пор пока
не будет уничтожен сам объект PooL, памЯть никогда не возвращаетсЯ
функции размещениЯ общего назначениЯ.
    Џриведем описание класса Pool:

         class Pool {

            struct Link { Link* next; }

            const unsigned esize;
            Link* head;

            Pool(Pool&amp;);            // защита от копированиЯ
            void operator= (Pool&amp;); // защита от копированиЯ
            void grow();
          public:
            Pool(unsigned n);
            ~Pool();

            void* alloc();
            void free(void* b);
          };

          inline void* Pool::alloc()
          {
            if (head==0) grow();
            Link* p = head;
            head = p->next;
            return p;
          }

          inline void Pool::free(void* b)
          {
            Link* p = (Link*) b;
            p->next = head;
            head = p;
          }

Џриведенные описаниЯ логично поместить в заголовочный файл Pool.h.
‘ледующие определениЯ могут находитьсЯ в любом месте программе и
завершают наш пример. Ћбъект Pool должен инициализироватьсЯ
конструктором:

          Pool::Pool(unsigned sz)
            : esize(sz)
          {
            head = 0;
          }

”ункциЯ Pool::grow() будет свЯзывать все элементы в список квантов
свободной памЯти head, образуЯ из них новый блок. ЋпределениЯ
остальных функций-членов оставлены в качестве упражнений 5 и 6 в
$$13.11.

          void Pool::grow()
          {
            const int overhead = 12;
            const int chunk_size = 8*1024-overhead;
            const int nelem = (chunk_size-esize)/esize;

            char* start = new char[chunk_size];
            char* last = &amp;start[(nelem-1)*esize];

            for (char* p = start; p&lt;last; p+=esize)
                ((Link*)p)->next = ((Link*)p)+1;
            ((Link*)last)->next = 0;
            head = (Link*)start;
          }

        13.11 “пражнениЯ

1. (*3) ‡авершите определениЯ функций-членов класса Type_info.
2. (*3) Џредложите такую структуру объекта Type_info, чтобы функциЯ
   Type_info::get_info() стала лишней, и перепишите с учетом этого
   функции-члены Type_info.
3. (*2.5) Ќасколько наглЯдно вы сможете записать примеры с Dialog_box,
   не используЯ макроопределениЯ (а также расширениЯ Языка)? Ќасколько
   наглЯдно вам удастсЯ записать их, используЯ расширениЯ Языка?
4. (*4) €сследуйте две широко распространенные библиотеки.
   Љлассифицируйте все библиотечные классы, разбив их на: конкретные
   типы, абстрактные типы, узловые классы, управлЯющие классы и
   интерфейсные классы. €спользуютсЯ ли абстрактные узловые классы
   и конкретные узловые классы? Њожно ли предложить более подходЯщее
   разбиение классов этих библиотек? €спользуетсЯ ли обширный
   интерфейс? Љакие имеютсЯ средства  динамической информации о типе
   (если они есть)? Љакова стратегиЯ управлениЯ памЯтью?
5. (*3) Ћпределите шаблонный вариант класса Pool из $$13.10.3. Џусть
   размер выделЯемого элемента памЯти будет параметром шаблона
   типа, а не конструктора.
6. (*2.5) “совершенствуйте шаблон типа Pool из предыдущего упражнениЯ
   так, чтобы некоторые элементы размещались во времЯ работы конструктора.
   ‘формулируйте в чем будет проблема переносимости, если использовать
   Pool с типом элементов char, покажите как ее устранить.
7. (*3) …сли ваша версиЯ ‘++ прЯмо не поддерживает динамические
   запросы о типе, обратитесь к своей основной библиотеке. ђеализован
   ли там механизм динамических запросов о типе? …сли это так,
   задайте операции из $$13.5 как надстройку над этим механизмом.
8. (*2.5) Ћпределите такой строковый класс, в котором нет никакого
   динамического контролЯ, и второй производный от него строковый
   класс, который только проводит динамический контроль и обращаетсЯ
   к первому. “кажите плюсы и минусы такого решениЯ по сравнению
   с решением,в котором делаетсЯ выборочный динамический контроль,
   сравните с подходом, использующим инварианты, как было предложено
   в $$12.2.7.1. Ќасколько можно совмещать эти подходы?
9. (*4) Ћпределите класс Storable как абстрактный базовый класс с
   виртуальными функциЯми writeout() и readin(). „лЯ простоты
   допустим, что длЯ заданиЯ нужного адресного пространства достаточно
   строки символов. ‘ помощью класса Storable реализуйте
   обмен объектами с диском. Џроверьте его на объектах нескольких
   классов по своему усмотрению.
10.(*4) Ћпределите базовый класс Persistent с операциЯми save()
   и nosave(), который будет проверЯть, что деструктор создал объект
   в определенной памЯти. Љакие еще полезные операции можно предложить?
   Џроверьте класс Persistent на нескольких классах по своему выбору.
   џвлЯетсЯ ли класс Persistent узловым классом, конкретным или
   абстрактным типом? Ђргументируйте ответ.
11.(*3) ‘оставьте только описание класса stack, который реализует
   стек с помощью операций create() (создать стек), delete()
   (уничтожить стек), push() (записать в стек) и pop() (читать из
   стека). €спользуйте только статические члены. „лЯ привЯзки и
   обозначениЯ стеков определите класс id. ѓарантируйте, что
   пользователь сможет копировать объекты stack::id, но не сможет
   работать с ними иным способом. ‘равните это определение стека
   с классом stack из $$8.2.
12.(*3) ‘оставьте описание класса stack, который ЯвлЯетсЯ абстрактным
   типом ($$13.3). Џредложите две различные реализации длЯ интерфейса,
   заданного stack. Ќапишите небольшую программу, работающую с
   этими классами. ‘равните это решение с классами, определЯющими
   стек, из предыдущего упражнениЯ и из $$8.2.
13.(*3) ‘оставьте такое описание класса stack, длЯ которого можно
   в динамике менЯть реализацию. Џодсказка: "‚сЯкую задачу можно
    решить, введЯ еще одну косвенность".
14.(*3.5) Ћпределите класс Oper, содержащий идентификатор (некоторого
   подходЯщего типа) и операцию (некоторый указатель на функцию).
   Ћпределите класс cat_object, содержащий список объектов Oper и
   объект типа void*. ‡адайте в классе cat_object операции:
   add_oper(), котораЯ добавлЯет объект к списку; remove_oper(id),
   котораЯ удалЯет из списка объект Oper c идентификатором id;
   operator() (id,arg), котораЯ вызывает функцию из объекта Oper c
   идентификатором id. ђеализуйте с помощью класса cat_object
   стек объектов Oper. Ќапишите небольшую программу, работающую
   с этими классами.
15.(*3) Ћпределите шаблон типа Object, служащий базовым классом
   длЯ cat_object. ‘ помощью Object реализуйте стек длЯ объектов
   класса String. Ќапишите небольшую программу, использующую этот
   шаблон типа.
16.(*3) Ћпределите вариант класса Object под именем Class, в котором
   объекты с одинаковым идентификатором имеют общий список операций.
   Ќапишите небольшую программу, использующую этот шаблон типа.
17.(*3) Ћпределите шаблон типа Stack, который задает традиционный
   и надежный интерфейс со стеком, реализуемым объектом шаблона
   типа Object. ‘равните это определение стека с классами, задающими
   стек, из предыдущих упражнений. Ќапишите небольшую программу,
   использующую этот шаблон типа.