ШАБЛОНЫ ТИПА

Вот ваша цитата

- Бьерн Страуструп

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

ВЫРАЖЕНИЯ И ОПЕРАТОРЫ

"Но с другой стороны не следует забывать про эффективность"

(Джон Бентли)

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

Группирование особых ситуаций

Особые ситуации естественным образом разбиваются на семейства. Действительно, логично представлять семейство Matherr, в которое входят Overflow (переполнение), Underflow (потеря значимости) и некоторые другие особые ситуации. Семейство Matherr образуют особые ситуации, которые могут запускать математические функции стандартной библиотеки.

Один из способов задания такого семейства сводится к определению Matherr как типа, возможные значения которого включают Overflow и все остальные:

enum { Overflow, Underflow, Zerodivide, /* ... */ };

try {

  // ...

}

catch (Matherr m) {

  switch (m) {

     case Overflow:

       // ...

     case Underflow:

       // ...

       // ...

  }

  // ...

}

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

class Matherr { };

class Overflow: public Matherr { };

class Underflow: public Matherr { };

class Zerodivide: public Matherr { };

// ...

Часто бывает так, что нужно обработать особую ситуацию Matherr не зависимо от того, какая именно ситуация из этого семейства произошла. Наследование позволяет сделать это просто:

try {

  // ...

}

catch (Overflow) {

  // обработка Overflow или любой производной ситуации

}

catch (Matherr) {

  // обработка любой отличной от Overflow ситуации

}

В этом примере Overflow разбирается отдельно, а все другие особые ситуации из Matherr разбираются как один общий случай. Конечно, функция, содержащая catch (Matherr), не будет знать какую именно особую ситуацию она перехватывает. Но какой бы она ни была, при входе в обработчик передаваемая ее копия будет Matherr. Обычно это как раз то, что нужно. Если это не так, особую ситуацию можно перехватить по ссылке (см. $$9.3.2).

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

try {

  // ...

}

catch (Overflow) { /* ... */ }

catch (Underflow) { /* ... */ }

catch (Zerodivide) { /* ... */ }

// ...

Это не только утомительно, но и опасно, поскольку можно забыть какую-нибудь особую ситуацию. Кроме того, необходимость перечислить в проверяемом блоке все особые ситуации практически гарантирует, что, когда семейство особых ситуаций библиотеки расширится, в программе пользователя возникнет ошибка. Это значит, что при введении новой особой ситуации в библиотеки математических функций придется перетранслировать все части программы, которые содержат обработчики всех особых ситуаций из Matherr. В общем случае такая перетрансляция неприемлема. Часто даже нет возможности найти все требующие перетрансляции части программы. Если такая возможность есть, нельзя требовать, чтобы всегда был доступен исходной текст любой части большой программы, или чтобы у нас были права изменять любую часть большой программы, исходный текст которой мы имеем. На самом деле, пользователь не должен думать о внутреннем устройстве библиотек. Все эти проблемы перетрансляции и сопровождения могут привести к тому, что после создания первой версии библиотеки будет нельзя вводить в ней новые особые ситуации. Но такое решение не подходит практически для всех библиотек.

Все эти доводы говорят за то, что особые ситуации нужно определять как иерархию классов (см. также $$9.6.1). Это, в свою очередь, означает, что особые ситуации могут быть членами нескольких групп:

class network_file_err             // ошибки файловой системы в сети

  : public network_err,            // ошибки сети

  public file_system_err {         // ошибки файловой системы

  // ...

};

Особую ситуацию network_file_err можно перехватить в функциях, обрабатывающих особые ситуации сети:

void f()

{

  try {

     // какие-то операторы

  }

  catch (network_err) {

     // ...

  }

}

Ее также можно перехватить в функциях, обрабатывающих особые ситуации

файловой системы:

void g()

{

  try {

     // какие-то другие операторы



  }

  catch (file_system_err) {

     // ...

  }

}

Это важный момент, поскольку такой системный сервис как работа в сети должен быть прозрачен, а это означает, что создатель функции g() может даже и не знать, что эта функция будет выполняться в сетевом режиме.

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

Поскольку можно сразу перехватить все особые ситуации (см. $$9.3.2), нет настоятельной необходимости создавать для этой цели общий, базовый для всех особых ситуаций, класс. Однако, если все особые ситуации являются производными от пустого класса Exception (особая ситуация), то в интерфейсах их использование становится более регулярным (см. $$9.6). Если вы используете общий базовый класс Exception, убедитесь, что в нем ничего нет кроме виртуального деструктора. В противном случае такой класс может вступить в противоречие с предполагаемым стандартом.

Иерархии классов

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

движущееся средство  

легковая машина 

аварийное средство

грузовая машина

полицейская машина

машина скорой помощи

пожарная машина

машина с выдвижной лестницей

Здесь класс Emergency представляет всю информацию, необходимую для моделирования аварийных движущихся средств, например: аварийная машина может нарушать некоторые правила движения, она имеет приоритет на перекрестках, находится под контролем диспетчера и т.д.

На С++ это можно задать так:

class Vehicle { /*...*/ };

class Emergency { /*   */ };

class Car : public Vehicle { /*...*/ };

class Truck : public Vehicle { /*...*/ };

class Police_car : public Car , public Emergency {

  //...

};

class Ambulance : public Car , public Emergency {

  //...

};

class Fire_engine : public Truck , Emergency {

  //...

};

class Hook_and_ladder : public Fire_engine {

  //...

};

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

движущееся средство (Vehicle {eptr})

легковая машина (Car)

грузовая машина (Truck)

полицейская машина (Police_car)

машина скорой помощи (Ambulance)

пожарная машина (Fire_engine)

машина с выдвижной лестницей (Hook_and_ladder)

Теперь класс Emergency используется просто как член в тех классах, которые представляют аварийные движущиеся средства:

class Emergency { /*...*/ };

class Vehicle { public: Emergency* eptr;  /*...*/ };

class Car : public Vehicle { /*...*/ };

class Truck : public Vehicle { /*...*/ };

class Police_car : public Car { /*...*/ };

class Ambulance : public Car { /*...*/ };

class Fire_engine : public Truck { /*...*/ };

class Hook_and_ladder : public Fire_engine { /*...*/ };

Здесь движущееся средство считается аварийным, если Vehicle::eptr не равно нулю. "Простые" легковые и грузовые машины инициализируются Vehicle::eptr равным нулю, а для других Vehicle::eptr должно быть установлено в ненулевое значение, например:

Car::Car()                         // конструктор Car

{

  eptr = 0;

}

Police_car::Police_car()           // конструктор Police_car

{

  eptr = new Emergency;

}

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

void f(Vehicle* p)

{

  delete p->eptr;

  p->eptr = 0;   // больше нет аварийного движущегося средства

  //...

  p->eptr = new Emergency;   // оно появилось снова

}

Так какой же вариант иерархии классов лучше? В общем случае ответ такой:



" Лучшей является программа, которая наиболее непосредственно отражает реальный мир". Иными словами, при выборе модели мы должны стремиться к большей ее"реальности", но с учетом неизбежных ограничений, накладываемых требованиями простоты и эффективности. Поэтому, несмотря на простоту преобразования обычного движущегося средства в аварийное, второе решение представляется непрактичным. Пожарные машины и машины скорой помощи – это движущиеся средства специального назначения со специально подготовленным персоналом, они действуют под управлением команд диспетчера, требующих специального оборудования для связи. Такое положение означает, что принадлежность к аварийным движущимся средствам - это базовое понятие, которое для улучшения контроля типов и применения  различных программных средств должно быть прямо представлено в программе. Если бы мы моделировали ситуацию, в которой назначение движущихся средств не столь определенно, скажем, ситуацию, в которой частный транспорт периодически используется для доставки специального персонала к месту происшествия, а связь обеспечивается с помощью портативных приемников, тогда мог бы оказаться подходящим и другой способ моделирования системы.

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

Иерархия классов

Производный класс сам в свою очередь может быть базовым классом:

class employee {                   /* ... */ };

class manager : public employee {  /* ... */ };

class director : public manager {  /* ... */ };

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

class temporary {                  /* ... */ };

class secretary : public employee { /* ... */ };

class tsec

  : public temporary, public secretary { /* ... */ };

class consultant

  : public temporary, public manager { /* ... */ };

Видим, что классы в С++ могут образовывать направленный ацикличный граф (подробнее об этом говорится в $$6.5.3). Этот граф для приведенных классов имеет вид:

Игнорирование классов

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

Однако там, где область приложения существенно отличается от традиционной последовательной обработки записей (или символов), или сложность задачи выше, как, например, в диалоговой системе CASE, недостаток языковой поддержки абстрактных данных из-за отказа от классов (если их не учитывать) повредит проекту. Сложность задачи не уменьшится, но, поскольку система реализована на обедненном языке,  структура программы плохо будет отвечать проекту. У нее слишком большой объем, не хватает проверки типов, и, вообще, она плохо приспособлена для использования различных вспомогательных средств. Это путь, приводящий к кошмарам при ее сопровождении.

Обычно для преодоления указанных трудностей создают специальные средства, поддерживающие понятия, используемые в проекте. Благодаря им создаются конструкции более высокого уровня и организуются проверки с целью компенсировать дефекты (или сознательное обеднение) языка реализации. Так метод проектирования становится самоцелью, и для него создается специальный язык программирования. Такие языки программирования в большинстве случаев являются плохой заменой широко распространенных языков программирования общего назначения, которые сопровождаются подходящими средствами проектирования. Использовать С++ с таким ограничением, которое должно компенсироваться при проектировании специальными средствами, бессмысленно. Хотя несоответствие между языком программирования и средствами проектирования может быть просто стадией процесса перехода, а значит временным явлением.

Самой типичной причиной игнорирования классов при проектировании является простая инерция. Традиционные языки программирования не предоставляют понятия класса, и в традиционных методах проектирования отражаются этот недостаток. Обычно в процессе проектирования наибольшее внимание уделяется разбиению задачи на процедуры, производящие требуемые действия. В главе 1 это понятие называлось процедурным программированием, а в области проектирования оно именуется как функциональная декомпозиция. Возникает типичный вопрос "Можно ли использовать С++ совместно с методом проектирования, базирующимся на функциональной декомпозиции?" Да, можно, но, вероятнее всего, в результате вы придете к использованию С++ как просто улучшенного С со всеми указанными выше проблемами. Это может быть приемлемо на период перехода на новый язык, или для уже завершенного проектирования, или для подзадач, в которых использование классов не дает существенных выгод (если учитывать опыт программирования на С++ к данному моменту), но в общем случае на большом отрезке времени отказ от свободного использования классов, связанный с методом функциональной декомпозиции, никак не совместим с эффективным использованием С++.

Процедурно-ориентированный и объектно-ориентированный подходы к программированию различаются по своей сути и обычно ведут к совершенно разным решениям одной задачи. Этот вывод верен как для стадии реализации, так и для стадии проектирования: вы концентрируете внимание или на предпринимаемых действиях, или на представляемых сущностях, но не на том и другом одновременно.

Тогда почему метод объектно-ориентированного проектирования предпочтительнее метода функциональной декомпозиции? Главная причина в том, что функциональная декомпозиция не дает достаточной абстракции данных. А отсюда уже следует, что проект будет

-

менее податливым к изменениям,

-          менее приспособленным для использования различных вспомогательных средств,

-          менее пригодным для параллельного развития и



-          менее пригодным для параллельного выполнения.

Дело в том, что функциональная декомпозиция вынуждает объявлять "важные" данные глобальными, поскольку, если система структурирована как дерево функций, всякое данное, доступное двум функциям, должно быть глобальным по отношению к ним. Это приводит к тому, что "важные" данные "всплывают" к вершине дерева, по мере того как все большее число функций требует доступа к ним.

В точности так же происходит в случае иерархии классов с одним корнем, когда "важные" данные всплывают по направлению к базовому классу.

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

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

Игнорирование наследования

Рассмотрим вариант 2 - проект, который игнорирует наследование. В этом случае в окончательной программе просто не используются возможности основного средства С++, хотя и получаются определенные выгоды при использовании С++ по сравнению с использованием языков С, Паскаль, Фортран, Кобол и т.п. Обычные доводы в пользу этого, помимо инерции, утверждения, что "наследование - это деталь реализации", или "наследование препятствует упрятыванию информации", или "наследование затрудняет взаимодействие с другими системами программирования".

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

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

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

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

Игнорирование статического контроля типов

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

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

Рассмотрим следующую аналогию: в физическом мире мы постоянно соединяем различные устройства, и существует кажущееся бесконечным число стандартов на соединения. Главная особенность этих соединений: они специально спроектированы таким образом, чтобы сделать невозможным соединение двух устройств, нерассчитанных на него, то есть соединение должно быть сделано единственным правильным способом. Вы не можете подсоединить электробритву к розетке с высоким напряжением. Если бы вы смогли сделать это, то сожгли бы бритву или сгорели сами. Масса изобретательности была проявлена, чтобы добиться невозможности соединения двух несовместимых устройств. Альтернативой одновременного использования нескольких несовместимых устройств может послужить такое устройство, которое само себя защищает от несовместимых с ним устройств, подключающихся к его входу. Хорошим примером может служить стабилизатор напряжения. Поскольку идеальную совместимость устройств нельзя гарантировать только на "уровне соединения", иногда требуется более дорогая защита в электрической цепи, которая позволяет в динамике приспособиться или (и) защититься от скачков напряжения.

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

Может получиться, что проект, совершенно разумный на абстрактном уровне,  столкнется с серьезными проблемами, если не учитывает ограничения базовых средств, в данном случае С++. Например, использование имен, а не типов для структурирования системы приведет к ненужным проблемам для системы типов С++ и, тем самым, может стать причиной ошибок и накладных расходов при выполнении. Рассмотрим три класса:

class X {                          // pseudo code, not C++

  f()

  g()

}

class Y {

  g()

  h()

}

class Z {

  h()

  f()

}

используемые некоторыми функциями бестипового проекта:

k(a, b, c)  // pseudo code, not C++

{

  a.f()

  b.g()

  c.h()

}

Здесь обращения

X x

Y y

Z z

k(x,y,z)  // ok

k(z,x,y)  // ok

будут успешными, поскольку k() просто требует, чтобы ее первый параметр имел операцию f(), второй параметр - операцию g(), а третий параметр - операцию h().  С другой стороны обращения

k(y,x,z);  // fail

k(x,z,y);  // fail

завершатся неудачно. Этот пример допускает совершенно разумные реализации на языках с полным динамическим контролем (например, Smalltalk или CLOS), но в С++ он не имеет прямого представления, поскольку язык требует, чтобы общность типов была реализована как отношение к базовому классу. Обычно примеры, подобные этому, можно представить на С++, если записывать утверждения об общности с помощью явных определений классов, но это потребует большого хитроумия и вспомогательных средств. Можно сделать, например, так:

class F {

  virtual void f();

};

class G {

  virtual void g();

};

class H {

  virtual void h();

};

class X : public virtual F, public virtual G {



  void f();

  void g();

};

class Y : public virtual G, public virtual H {

  void g();

  void h();

};

class Z : public virtual H, public virtual F {

  void h();

  void f();

};

k(const F& a, const G& b, const H& c)

{

  a.f();

  b.g();

  c.h();

}

main()

{

  X x;

  Y y;

  Z z;

  k(x,y,z);  // ok

  k(z,x,y);  // ok

  k(y,x,z);  // error F required for first argument

  k(x,z,y);  // error G required for second argument

}

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

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

ИМЕНА

Имя (идентификатор) является последовательностью букв или цифр. Первый символ должен быть буквой. Буквой считается и символ подчеркивания _. Язык С++ не ограничивает число символов в имени. Но в реализацию входят программные компоненты, которыми создатель транслятора управлять не может (например, загрузчик), а они, к сожалению, могут устанавливать ограничения. Кроме того, некоторые системные программы, необходимые для выполнения программы на С++, могут расширять или сужать множество символов, допустимых в идентификаторе. Расширения (например, использование $ в имени) могут нарушить переносимость программы. Нельзя использовать в качестве имен служебные слова С++ (см. $$R.2.4), например:

hello    this_is_a_most_unusially_long_name

DEFINED  foO    bAr     u_name    HorseSense

var0     var1   CLASS   _class    ___

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

012      a fool    $sys     class    3var

pay.due  foo~bar   .name    if

Заглавные и строчные буквы считаются различными, поэтому Count и count - разные имена. Но выбирать имена, почти не отличающиеся друг от друга, неразумно. Все имена, начинающиеся с символа подчеркивания, резервируются для использования в самой реализации или в тех программах, которые выполняются совместно с рабочей, поэтому крайне легкомысленно вставлять такие имена в свою программу.  При разборе программы транслятор всегда стремится выбрать самую длинную последовательность символов, образующих имя, поэтому var10 - это имя, а не идущие подряд имя var и число 10. По той же причине elseif - одно имя (служебное), а не два служебных имени else и if.

Имена особых ситуаций

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

class Vector {

  public:

     class Range {

       public:

          int index;

          Range(int i) : index(i) { }

     };

     // ...

     int& operator[](int i)

};

int Vector::operator[](int i)

{

  if (o<=i && i <sz) return p[i];

  throw Range(i);

}

Чтобы исследовать недопустимое значение индекса, в обработчике нужно дать имя объекту, представляющему особую ситуацию:

void  f(Vector& v)

{

  // ...

  try {

     do_something(v);

  }

  catch (Vector::Range r ) {

     cerr << "недопустимый индекс" << r.index << '\n';

     // ...

  }

  // ...

}

Конструкция в скобках после служебного слова catch является по сути описанием и она аналогична описанию формального параметра функции. В ней указывается каким может быть тип параметра (т.е. особой ситуации) и может задаваться имя для фактической, т.е. запущенной, особой ситуации. Вспомним, что в шаблонах типов у нас был выбор для именования особых ситуаций. В каждом созданном по шаблону классе был свой класс особой ситуации:

template<class T> class Allocator {

  // ...

  class Exhausted { }

  // ...

  T* get();

};

void f(Allocator<int>& ai, Allocator<double>& ad)

{

  try {

     // ...

  }

  catch (Allocator<int>::Exhausted) {

     // ...

  }

  catch (Allocator<double>::Exhausted) {

     // ...

  }

}

С другой стороны, особая ситуация может быть общей для всех созданных по шаблону классов:

class Allocator_Exhausted { };

template<class T> class Allocator {

  // ...

  T* get();

};

void f(Allocator<int>& ai, Allocator<double>& ad)

{

  try {

     // ...

  }

  catch (Allocator_Exhausted) {

     // ...

  }

}

Какой способ задания особой ситуации предпочтительней, сказать трудно. Выбор зависит от назначения рассматриваемого шаблона.

Индексация

Операторная функция operator[] задает для объектов классов интерпретацию индексации. Второй параметр этой функций (индекс) может иметь произвольный тип. Это позволяет, например, определять ассоциативные массивы. В качестве примера можно переписать определение из $$2.3.10, где ассоциативный массив использовался в небольшой программе, подсчитывающей число вхождений слов в файле. Там для этого использовалась функция. Мы определим настоящий тип ассоциативного массива:

class assoc {

  struct pair {

     char* name;

     int val;

  };

  pair* vec;

  int max;

  int free;

  assoc(const assoc&);             // предотвращает копирование

  assoc& operator=(const assoc&);  // предотвращает копирование

  public:

     assoc(int);

     int& operator[](const char*);

     void print_all();

};

В объекте assoc хранится вектор из структур pair размером max. В переменной free хранится индекс первого свободного элемента вектора.

Чтобы предотвратить копирование объектов assoc, конструктор копирования и операция присваивания описаны как частные. Конструктор выглядит так:

assoc::assoc(int s)

{

  max = (s<16) ? 16 : s;

  free = 0;

  vec = new pair[max];

}

В реализации используется все тот же неэффективный алгоритм поиска,

что и в $$2.3.10. Но теперь, если вектор переполняется, объект assoc увеличивается:

#include <string.h>

int& assoc::operator[](const char* p)

/*

  работает с множеством пар (структур pair):

  проводит поиск p, возвращает ссылку на целое значение из найденной пары,

  создает новую пару, если p не найдено

*/

{

  register pair* pp;

  for (pp=&vec[free-1]; vec<=pp; pp-- )

     if (strcmp(p,pp->name) == 0) return pp->val;

  if (free == max) {               //переполнение: вектор увеличивается

     pair* nvec = new pair[max*2];

     for (int i=0; i<max; i++) nvec[i] = vec[i];

       delete vec;

     vec = nvec;

     max = 2*max;

  }

  pp = &vec[free++];

  pp->name = new char[strlen(p)+1];

  strcpy(pp->name,p);

  pp->val = 0;                     // начальное значение = 0

  return pp->val;

}

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

void assoc::print_all()

{

  for (int i = 0; i<free; i++)

     cout << vec[i].name << ": " << vec[i].val << '\n';

}

Наконец, можно написать тривиальную программу:

main()    // подсчет числа вхождений во входной

          // поток каждого слова

{

  const MAX = 256;  // больше длины самого длинного слова

  char buf[MAX];

  assoc vec(512);

  while (cin>>buf) vec[buf]++;

  vec.print_all();

}

Опытные программисты могут заметить, что второй комментарий можно легко опровергнуть. Решить возникающую здесь проблему предлагается в упражнении $$7.14 [20]. Дальнейшее развитие понятие ассоциативного массива получит в $$8.8.

Функция operator[]() должна быть членом класса. Отсюда следует, что эквивалентность x[y] == y[x] может не выполняться, если x объект класса. Обычные отношения эквивалентности, справедливые для операций со встроенными типами, могут не выполняться для пользовательских типов ($$7.2.2, см. также $$7.9).

Информация о типе

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

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

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

typeid static_type_info(type) // получить typeid для имени типа

typeid ptr_type_info(pointer) // получить typeid для указателя

typeid ref_type_info(reference) // получить typeid для ссылки

pointer ptr_cast(type,pointer)  // преобразование указателя

reference ref_cast(type,reference)  // преобразование ссылки

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

Большинство пользователей, которым вообще нужна динамическая идентификация типа, может ограничиться операциями приведения ptr_cast() и ref_cast(). Таким образом пользователь отстраняется от дальнейших сложностей, связанных с динамической идентификацией типа. Кроме того, ограниченное использование динамической информации о типе меньше всего чревато ошибками.

Если недостаточно знать, что операция приведения прошла успешно, а нужен истинный тип (например, объектно-ориентированный ввод-вывод), то можно использовать операции динамических запросов о типе: static_type_info(), ptr_type_info() и ref_type_info(). Эти операции возвращают объект класса typeid. Как было показано в примере с set и slist_set, объекты класса typeid можно сравнивать. Для большинства задач этих сведений о классе typeid достаточно. Но для задач, которым нужна более полная информация о типе, в классе typeid есть функция get_type_info():

class typeid {

  friend class Type_info;

  private:

     const Type_info* id;

  public:

     typeid(const Type_info* p) : id(p) { }

     const Type_info* get_type_info() const { return id; }

     int operator==(typeid i) const ;

};

Функция get_type_info() возвращает указатель на неменяющийся (const) объект класса Type_info из typeid. Существенно, что объект не меняется: это должно гарантировать, что динамическая информация о типе отражает статические типы исходной программы. Плохо, если при выполнении программы некоторый тип может изменяться.

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

Инициализация

Инициализация объектов класса с помощью таких функций как set_date() - неэлегантное и чреватое ошибками решение. Поскольку явно не было указано, что объект требует инициализации, программист может либо забыть это сделать, либо сделать дважды, что может привести к столь же катастрофическим последствиям. Лучше дать программисту возможность описать функцию, явно предназначенную для инициализации объектов. Поскольку такая функция конструирует значение данного типа, она называется конструктором. Эту функцию легко распознать - она имеет то же имя, что и ее класс:

class date {

  // ...

  date(int, int, int);

};

Если в классе есть конструктор, все объекты этого класса будут проинициализированы. Если конструктору требуются параметры, их надо указывать:

date today = date(23,6,1983);

date xmas(25,12,0);                // краткая форма

date my_birthday;                  // неправильно, нужен инициализатор

Часто бывает удобно указать несколько способов инициализации объекта. Для этого нужно описать несколько конструкторов:

class date {

  int month, day, year;

  public:

     // ...

     date(int, int, int);           // день, месяц, год

     date(int, int);                // день, месяц и текущий год

     date(int);                     // день и текущие год и месяц

     date();                            // стандартное значение: текущая дата

  date(const char*);               // дата в строковом представлении

};

Параметры конструкторов подчиняются тем же правилам о типах

параметров, что и все остальные функции ($$4.6.6). Пока конструкторы достаточно различаются по типам своих параметров, транслятор способен правильно выбрать конструктор:

date today(4);

date july4("July 4, 1983");

date guy("5 Nov");

date now;                          // инициализация стандартным значением

Размножение конструкторов в примере c date типично. При разработке класса всегда есть соблазн добавить еще одну возможность, - а вдруг она кому-нибудь пригодится. Чтобы определить действительно нужные возможности, надо поразмышлять, но зато в результате, как правило, получается более компактная и понятная программа. Сократить число сходных функций можно с помощью стандартного значения параметра. В примере с date для каждого параметра можно задать стандартное значение, что означает: "взять значение из текущей даты".

class date {

  int month, day, year;

  public:

     // ...

     date(int d =0, int m =0, y=0);

     // ...

};

date::date( int d, int m, int y)

{

  day = d ? d : today.day;

  month = m ? m : today.month;

  year = y ? y : today.year;

  // проверка правильности даты

  // ...

}

Когда используется стандартное значение параметра, оно должно отличаться от всех допустимых значений параметра. В случае месяца и дня очевидно, что при значении нуль - это так, но неочевидно, что нуль подходит для значения года. К счастью, в европейском календаре нет нулевого года, т.к. сразу после 1 г. до р.х. (year==-1) идет 1 г. р.х. (year==1). Однако для обычной программы это, возможно, слишком тонкий момент.

Объект класса без конструктора может инициализироваться присваиванием ему другого объекта этого же класса. Это незапрещено и в том случае, когда конструкторы описаны:

date d = today;  // инициализация присваиванием

На самом деле, имеется стандартный конструктор копирования, определенный как поэлементное копирование объектов одного класса. Если такой конструктор для класса X не нужен, можно переопределить его как конструктор копирования X::X(const X&). Подробнее поговорим об этом в $$7.6.

Инициализация и удаление

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

Например:

class vector

{

  // ...

  public:

     void init ( init size );       // вызов init () перед первым

                                   // использованием объекта vector

     // ...

};

void f ()

{

  vector v;

  // пока v нельзя использовать

  v.init ( 10 );

  // теперь можно

}

Но это некрасивое и чреватое ошибками решение. Будет лучше, если создатель типа определит для инициализации переменных некоторую специальную функцию. Если такая функция есть, то две независимые операции размещения и инициализации переменной совмещаются в одной (иногда ее называют инсталляцией или просто построением). Функция инициализации называется конструктором. Конструктор выделяется среди всех прочих функций данного класса тем, что имеет такое же имя, как и сам класс. Если объекты некоторого типа строятся нетривиально, то нужна еще одна дополнительная операция для удаления их после последнего использования. Функция удаления в С++ называется деструктором.  Деструктор имеет то же имя, что и его класс, но перед ним стоит символ ~ (в С++ этот символ используется для операции дополнения).  Приведем пример:

class vector

{

  int  sz;                         // число элементов

  int * v;                         // указатель на целые

  public:

     vector ( int );                // конструктор

     ~vector ();                    // деструктор

     int& operator [] ( int index ); // операция индексации

};

Конструктор класса vector можно использовать для контроля над ошибками и выделения памяти:

vector::vector ( int s )

{

  if ( s <= 0 )

     error ( "недопустимый размер вектора" );

  sz = s;

  v = new int [ s ];               // разместить массив из s целых

}

Деструктор класса vector освобождает использовавшуюся память:

vector::~vector ()

{

  delete [] v;                     // освободить массив, на который

                                   // настроен указатель v

}

От реализации С++ не требуется освобождения выделенной с помощью new

памяти, если на нее больше не ссылается ни один указатель (иными словами, не требуется автоматическая "сборка мусора"). В замен этого можно без вмешательства пользователя определить в классе собственные функции управления памятью. Это типичный способ применения конструкторов и деструкторов, хотя есть много не связанных с управлением памятью применений этих функций (см., например, $$9.4).

Инкапсуляция

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

class window

{

  // ...

  protected:

     Rectangle inside;

     // ...

};

class dumb_terminal : public window

{

     // ...

     public:

       void prompt ();

       // ...

};

Здесь в базовом классе window член inside типа Rectangle описывается как защищенный (protected), но функции-члены производных классов, например, dumb_terminal::prompt(), могут обратиться к нему и выяснить, с какого вида окном они работают. Для всех других функций член window::inside недоступен.

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

Неочевидное следствие из этого: нельзя составить полный и окончательный список всех функций, которым будет доступен защищенный член, поскольку всегда можно добавить еще одну, определив ее как функцию-член в новом производном классе. Для метода абстракции данных такой подход часто бывает мало приемлемым. Если язык ориентируется на метод абстракции данных, то очевидное для него решение - это требование указывать в описании класса список всех функций, которым нужен доступ к члену.  В С++ для этой цели используется описание частных (private) членов. Оно использовалось и в приводившихся описаниях классов complex и shape.

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

Инкремент и декремент

Операция ++ явно задает инкремент в отличие от неявного его задания с помощью сложения и присваивания. По определению ++lvalue означает lvalue+=1, что, в свою очередь  означает lvalue=lvalue+1 при условии, что содержимое lvalue не вызывает побочных эффектов. Выражение, обозначающее операнд инкремента, вычисляется только один раз. Аналогично обозначается операция декремента (--). Операции ++ и – могут использоваться как префиксные и постфиксные операции.  Значением ++x является новое (т. е. увеличенное на 1) значение x. Например, y=++x эквивалентно y=(x+=1). Напротив, значение x++ равно прежнему значению x. Например, y=x++ эквивалентно y=(t=x,x+=1,t), где t - переменная того же типа, что и x.

Напомним, что операции инкремента и декремента указателя эквивалентны сложению 1 с указателем или вычитанию 1 из указателя, причем вычисление происходит в элементах массива, на который настроен указатель. Так, результатом  p++ будет указатель на следующий элемент. Для указателя p типа T* следующее соотношение верно по определению:

long(p+1) == long(p) + sizeof(T);

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

inline void cpy(char* p, const char* q)

{

  while (*p++ = *q++) ;

}

Язык С++ (подобно С) имеет как сторонников, так и противников именно из-за такого сжатого, использующего сложные выражения стиля программирования. Оператор

while (*p++ = *q++) ;

вероятнее всего, покажется невразумительным для незнакомых с С. Имеет смысл повнимательнее посмотреть на такие конструкции, поскольку для C и C++ они не является редкостью.

Сначала рассмотрим более традиционный способ копирования массива символов:

int length = strlen(q)

for (int i = 0; i<=length; i++) p[i] = q[i];

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

for (int i = 0; q[i] !=0 ; i++) p[i] = q[i];

p[i] = 0;                          // запись нулевого символа

Поскольку p и q - указатели, можно обойтись без переменной i, используемой для индексации:

while (*q !=0) {

  *p = *q;

  p++;                             // указатель на следующий символ

  q++;                             // указатель на следующий символ

}

*p = 0;                                 // запись нулевого символа

Поскольку операция постфиксного инкремента позволяет сначала использовать значение, а затем уже увеличить его, можно переписать цикл так:

while (*q != 0) {

  *p++ = *q++;

}

*p = 0;                                 // запись нулевого символа

Отметим, что результат выражения  *p++ = *q++ равен *q. Следовательно, можно переписать наш пример и так:

while ((*p++ = *q++) != 0)  { }

В этом варианте учитывается, что *q равно нулю только тогда, когда *q  уже скопировано в *p, поэтому можно исключить завершающее присваивание нулевого символа. Наконец, можно еще более сократить запись этого примера, если учесть, что пустой блок не нужен, а операция "!= 0" избыточна, т.к. результат условного выражения и так всегда сравнивается с нулем.  В результате мы приходим к первоначальному варианту, который вызывал недоумение:

while (*p++ = *q++) ;

Неужели этот вариант труднее понять, чем приведенные выше? Только неопытным программистам на С++ или С! Будет ли последний вариант наиболее эффективным по затратам времени и  памяти?  Если  не  считать первого варианта с функцией strlen(), то это неочевидно. Какой из вариантов окажется эффективнее, определяется как спецификой системы команд, так и возможностями транслятора. Наиболее эффективный алгоритм копирования для вашей машины можно найти в стандартной функции копирования строк из файла <string.h>:

int strcpy(char*, const char*);

Интерфейсные классы

Про один из самых важных видов классов обычно забывают - это "скромные"

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

Интерфейсный класс в чистом виде даже не требует генерации кода. Вспомним описание шаблона типа Splist из $$8.3.2:

template<class T>

  class Splist : private Slist<void*> {

  public:

     void insert(T* p) { Slist<void*>::insert(p); }

     void append(T* p) { Slist<void*>::append(p); }

     T* get() { return (T*) Slist<void*>::get(); }

};

Класс Splist преобразует список ненадежных обобщенных указателей типа void* в более удобное семейство надежных классов, представляющих списки. Чтобы применение интерфейсных классов не было слишком накладно, нужно использовать функции-подстановки. В примерах, подобных приведенному, где задача функций-подстановок только подогнать тип, накладные расходы в памяти и скорости выполнения программы не возникают.

Естественно, можно считать интерфейсным абстрактный базовый класс, который представляет абстрактный тип, реализуемый конкретными типами ($$13.3), также как и управляющие классы из раздела 13.9. Но здесь мы рассматриваем классы, у которых нет иных назначений - только задача адаптации интерфейса.

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

class Window {

  // ...

  virtual void draw();

};

class Cowboy {

  // ...

  virtual void draw();

};

class CowboyWindow : public Cowboy, public Window {

  // ...

};

В этой игре класс CowboyWindow представляет движение ковбоя на экране

и управляет взаимодействием игрока с ковбоем. Очевидно, появится много полезных функций, определенных в классе Window и Cowboy, поэтому предпочтительнее использовать множественное наследование, чем описывать Window или Cowboy как члены. Хотелось бы передавать этим функциям в качестве параметра объект типа CowboyWindow, не требуя от программиста указания каких-то спецификаций объекта. Здесь как раз и возникает вопрос, какую функции выбрать для CowboyWindow: Cowboy::draw() или Window::draw().

В классе CowboyWindow может быть только одна функция с именем draw(), но поскольку полезная функция работает с объектами Cowboy или Window и ничего не знает о CowboyWindow, в классе CowboyWindow должны подавляться (переопределяться) и функция Cowboy::draw(), и функция Window_draw(). Подавлять обе функции с помощью одной - draw() неправильно, поскольку, хотя используется одно имя, все же все функции draw() различны и не могут переопределяться одной.

    Наконец, желательно, чтобы в классе CowboyWindow наследуемые функции Cowboy::draw() и Window::draw() имели различные однозначно заданные имена.

Для решения этой задачи нужно ввести дополнительные классы для Cowboy и Window. Вводится два новых имени для функций draw() и гарантируется, что их вызов в классах Cowboy и Window приведет к вызову функций с новыми именами:

class CCowboy : public Cowboy {

  virtual int cow_draw(int) = 0;

  void draw() { cow_draw(i); } // переопределение Cowboy::draw

};

class WWindow : public Window {

  virtual int win_draw() = 0;

  void draw() { win_draw(); } // переопределение Window::draw

};

Теперь с помощью интерфейсных классов CCowboy и WWindow можно определить класс CowboyWindow и сделать требуемые переопределения функций cow_draw() и win_draw:



class CowboyWindow : public CCowboy, public WWindow {

  // ...

  void cow_draw();

  void win_draw();

};

Отметим, что в действительности трудность возникла лишь потому, что у обеих функций draw()  одинаковый тип параметров. Если бы типы параметров различались, то обычные правила разрешения неоднозначности при перегрузке гарантировали бы, что трудностей не возникнет, несмотря на наличие различных функций с одним именем.

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

Функции-переходники CCowboy::draw() и WWindow_draw являются виртуальными, и простая оптимизация с помощью подстановки невозможна. Однако, есть возможность, что транслятор распознает такие функции и удалит их из цепочки вызовов.

Интерфейсные функции служат для приспособления интерфейса к запросам пользователя. Благодаря им в интерфейсе собираются операции, разбросанные по всей программе. Обратимся к классу vector из $$1.4. Для таких векторов, как и для массивов, индекс отсчитывается от нуля. Если пользователь хочет работать с диапазоном индексов, отличным от диапазона 0..size-1, нужно сделать соответствующие приспособления, например, такие:



void f()

{

  vector v(10);  // диапазон [0:9]

  // как будто v в диапазоне [1:10]:

  for (int i = 1; i<=10; i++) {

     v[i-1] = ... // не забыть пересчитать индекс

  }

  // ...

}

Лучшее решение дает класс vec c произвольными границами индекса:

class vec : public vector {

  int lb;

  public:

     vec(int low, int high)

     : vector(high-low+1) { lb=low; }

     int& operator[](int i)

       { return vector::operator[](i-lb); }

     int low() { return lb; }

     int high() { return lb+size() - 1; }

};

Класс vec можно использовать без дополнительных операций, необходимых в первом примере:

void g()

{

  vec v(1,10);  // диапазон [1:10]

  for (int i = 1; i<=10; i++) {

     v[i] = ...

  }

  // ...

}

Очевидно, вариант с классом vec нагляднее и безопаснее.

Интерфейсные классы имеют и другие важные области применения, например, интерфейс между программами на С++ и программами на другом языке ($$12.1.4) или интерфейс с особыми библиотеками С++.

Интерфейсы и реализации

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

Очевидные примеры хороших классов дают контейнеры разных видов: таблицы, множества, списки, вектора, словари и т.д. Такой класс имеет операцию занесения в контейнер. Обычно имеется и операция проверки: был ли данный член занесен в контейнер? Могут быть операции упорядочивания всех членов и просмотра их в определенном порядке. Наконец, может быть операция удаления члена. Обычно контейнерные классы имеют конструкторы и деструкторы.

Инварианты

Значение членов или объектов, доступных с помощью членов класса, называется состоянием объекта (или просто значением объекта). Главное при построении класса - это: привести объект в полностью определенное состояние (инициализация), сохранять полностью определенное состояние обЪекта в процессе выполнения над ним различных операций, и в конце работы уничтожить объект без всяких последствий. Свойство, которое делает состояние объекта полностью определенным, называется инвариантом.

Поэтому назначение инициализации - задать конкретные значения, при которых выполняется инвариант объекта. Для каждой операции класса предполагается, что инвариант должен иметь место перед выполнением операции и должен сохраниться после операции. В конце работы деструктор нарушает инвариант, уничтожая объект. Например, конструктор String::String(const char*) гарантирует, что p указывает на массив из, по крайней мере, sz элементов, причем sz имеет осмысленное значение и v[sz-1]==0. Любая строковая операция не должна нарушать это утверждение.

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

Понятие инварианта появилось в работах Флойда, Наура и Хора, посвященных пред- и пост-условиям, оно встречается во всех важных статьях по абстрактным типам данных и верификации программ за последние 20 лет. Оно же является основным предметом отладки в C++.

Обычно, в течение работы функции- члена инвариант не сохраняется. Поэтому функции, которые могут вызываться в те моменты, когда инвариант не действует, не должны входить в общий интерфейс класса. Такие функции должны быть частными или защищенными.

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

class String {

  int sz;

  int* p;

  public:

     class Range {};

     class Invariant {};

     void check();

     String(const char* q);

     ~String();

     char& operator[](int i);

     int size() { return sz; }

  //...

};

void String::check()

{

  if (p==0 || sz<0 || TOO_LARGE<=sz || p[sz-1])

     throw Invariant;

}

char& String::operator[](int i)

{

  check();                         // проверка на входе

  if (i<0 || i<sz) throw Range;    // действует

  check();                         // проверка на выходе

  return v[i];

}

Этот вариант прекрасно работает и не осложняет жизнь программиста. Но для такого простого класса как String проверка инварианта будет занимать большую часть времени счета. Поэтому программисты обычно выполняют проверку инварианта только при отладке:

inline void String::check()

{

  if (!NDEBUG)

     if (p==0 || sz<0 || TOO_LARGE<=sz || p[sz])

       throw Invariant;

}

Мы выбрали имя NDEBUG, поскольку это макроопределение, которое используется для аналогичных целей в стандартном макроопределении С assert(). Традиционно NDEBUG устанавливается с целью указать, что отладки нет. Указав, что check() является подстановкой, мы гарантировали, что никакая программа не будет создана, пока константа NDEBUG не будет установлена в значение, обозначающее отладку. С помощью шаблона типа Assert() можно задать менее регулярные утверждения, например:

template<class T, class X> inline void Assert(T expr,X x)

{

  if (!NDEBUG)

    if (!expr) throw x;

}

вызовет особую ситуацию x, если expr ложно, и мы не отключили проверку с помощью NDEBUG. Использовать Assert() можно так:



class Bad_f_arg { };

void f(String& s, int i)

{

  Assert(0<=i && i<s.size(),Bad_f_arg());

  //...

}

Шаблон типа Assert() подражает макрокоманде assert() языка С. Если i не находится в требуемом диапазоне, возникает особая ситуация Bad_f_arg.

С помощью отдельной константы или константы из класса проверить подобные утверждения или инварианты - пустяковое дело. Если же необходимо проверить инварианты с помощью объекта, можно определить производный класс, в котором проверяются операциями из класса, где нет проверки, см. упр.8 в $$13.11.

Для классов с более сложными операциями расходы на проверки могут быть значительны, поэтому проверки можно оставить только для "поимки" трудно обнаруживаемых ошибок. Обычно полезно оставлять по крайней мере несколько проверок даже в очень хорошо отлаженной программе. При всех условиях сам факт определения инвариантов и использования их при отладке дает неоценимую помощь для получения правильной программы и, что более важно, делает понятия, представленные классами, более регулярными и строго определенными. Дело в том, что когда вы создаете инварианты, то рассматриваете класс с другой точки зрения и вносите определенную избыточность в программу. То и другое увеличивает вероятность обнаружения ошибок, противоречий и недосмотров. Мы указали в $$11.3.3.5, что две самые общие формы преобразования иерархии классов состоят в разбиении класса на два и в выделении общей части двух классов в базовый класс. В обоих случаях хорошо продуманный инвариант может подсказать возможность такого преобразования. Если, сравнивая инвариант с программами операций, можно обнаружить, что большинство проверок инварианта излишни, то значит класс созрел для разбиения. В этом случае подмножество операций имеет доступ только к подмножеству состояний объекта. Обратно, классы созрели для слияния, если у них сходные инварианты, даже при некотором различии в их реализации.

Исчерпание ресурса

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

1.

Повторный запрос: пользователь должен изменить свой запрос и повторить его.

2.       Завершение: запросить дополнительные ресурсы от системы, если их нет, запустить особую ситуацию.

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

В С++ первый способ поддержан механизмом вызова функций, а второй - механизмом особых ситуаций. Оба способа можно продемонстрировать на примере реализации и использования операции new:

#include <stdlib.h>

extern void* _last_allocation;

extern void* operator new(size_t size)

{

  void* p;

  while ( (p=malloc(size))==0 ) {

     if (_new_handler)

       (*_new_handler)();  // обратимся за помощью

     else

       return 0;

  }

  return _last_allocation=p;

}

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

void my_new_handler()

{

  try_find_some_memory();          // попытаемся найти

                                   // свободную память

  if (found_some()) return;        // если она найдена, все в порядке

  throw Memory_exhausted();        // иначе запускаем особую

                                   // ситуацию "Исчерпание_памяти"

}

Где-то в программе должен быть проверяемый блок с соответствующим обработчиком:

try {

  // ...

}

catch (Memory_exhausted) {

  // ...

}

В функции operator new() использовался указатель на управляющую функцию _new_handler, который настраивается стандартной функцией set_new_handler(). Если нужно настроиться на собственную управляющую функцию, надо обратиться так

set_new_handler(&my_new_handler);

Перехватить ситуацию Memory_exhausted можно следующим образом:

void (*oldnh)() = set_new_handler(&my_new_handler);

try {

  // ...

}

catch (Memory_exhausted) {

  // ...

}

catch (...) {

  set_new_handler(oldnh);          // восстановить указатель на

                                   // управляющую функцию

  throw();                         // повторный запуск особой ситуации

}

set_new_handler(oldnh);            // восстановить указатель на

                                   // управляющую функцию

Можно поступить еще лучше, если к управляющей функции применить описанный в $$9.4 метод "запроса ресурсов путем инициализации" и убрать обработчик catch (...).

В решении, использующим my_new_handler(), от точки обнаружения ошибки до функции, в которой она обрабатывается, не передается никакой информации. Если нужно передать какие-то данные, то пользователь может включить свою управляющую функцию в класс. Тогда в функции, обнаружившей ошибку, нужные данные можно поместить в объект этого класса. Подобный способ, использующий объекты-функции, применялся в $$10.4.2 для реализации манипуляторов. Способ, в котором используется указатель на функцию или объект-функция для того, чтобы из управляющей функции, обслуживающей некоторый ресурс, произвести "обратный вызов" функции запросившей этот ресурс, обычно называется просто обратным вызовом (callback).

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

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

Использование моделей

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

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

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

Естественно, что выбор начальной модели является важным решением, и обычно оно принимается только после поиска потенциальных моделей и тщательной оценки вариантов. Более того, во многих случаях модель подходит только при условии понимания того, что потребуются значительные изменения для воплощения ее идей в иной области приложения. Но проектирование программного обеспечения – тяжелый труд, и надо использовать любую помощь. Не следует отказываться от использования моделей из-за неоправданного пренебрежения к имитации. Имитация - не что иное, как форма искреннего восхищения, а, с учетом права собственности и авторского права, использование моделей и предшествующих работ в качестве источника вдохновения - допустимый способ для всех новаторских работ во всех видах деятельности. То, что было позволено Шекспиру, подходит и для нас. Некоторые обозначают использование моделей в процессе проектирования как "проектирование повторного использования".

Историческая справка

Безусловно С++ многим обязан языку С [8], который сохраняется как его подмножество. Сохранены и все свойственные С средства низкого уровня, предназначенные для решения самых насущных задач системного программирования. С, в свою очередь, многим обязан своему предшественнику языку BCPL [13]. Комментарий языка BCPL был восстановлен в С++.  Если читатель знаком с языком BCPL, то может заметить, что в С++ по-прежнему нет блока VALOF. Еще одним источником вдохновения был язык SIMULA-67 [2,3]; именно из него была заимствована концепция классов (вместе c производными классами и виртуальными функциями).  Оператор inspect из SIMULA-67 намеренно не был включен в С++.  Причина – желание способствовать модульности за счет использования виртуальных функций. Возможность в С++ перегрузки операций и свобода размещения описаний всюду, где может встречаться оператор, напоминают язык Алгол-68 [24].

С момента выхода в свет первого издания этой книги язык С++ подвергся существенным изменениям и уточнениям. В основном это касается разрешения неоднозначности при перегрузке, связывании и управлении памятью. Вместе с тем, были внесены незначительные изменения с целью увеличить совместимость с языком С. Были также введены некоторые обобщения и существенные расширения, как то: множественное наследование, функции-члены со спецификациями static и const, защищенные члены (protected), шаблоны типа и обработка особых ситуаций. Все эти расширения и доработки были нацелены на то, чтобы С++ стал языком, на котором можно создавать и использовать библиотеки. Все изменения описываются в [10,18,20,21 и 23].

Шаблоны типов появились частично из-за желания формализовать макросредства, а частично были инспирированы описанием генерических объектов в языке Ада (с учетом их достоинств и недостатков) и параметризированными модулями языка CLU. Механизм обработки особых ситуаций появился отчасти под влиянием языков Ада и CLU [11], а отчасти под влиянием ML [26]. Другие расширения, введенные за период между 1985 и 1991 г.г. (такие как множественное наследование, статические функции-члены и чистые виртуальные функции), скорее появились в результате обобщения опыта программирования на С++, чем были почерпнуты из других языков.

Более ранние версии языка, получившие название "С с классами" [16], использовались, начиная с 1980 г. Этот язык возник потому, что автору потребовалось написать программы моделирования, управляемые прерываниями. Язык SIMULA-67 идеально подходит для этого, если не учитывать эффективность. Язык "С с классами" использовался для больших задач моделирования. Строгой проверке подверглись тогда возможности написания на нем программ, для которых критичны ресурсы времени и памяти. В этом языке недоставало перегрузки операций, ссылок, виртуальных функций и многих других возможностей.  Впервые С++ вышел за пределы исследовательской группы, в которой работал автор, в июле 1983 г., однако тогда многие возможности С++ еще не были разработаны.

Название С++ (си плюс плюс) , было придумано Риком Маскитти летом 1983 г. Это название отражает эволюционный характер изменений языка С. Обозначение ++ относится к операции наращивания С. Чуть более короткое имя С+ является синтаксической ошибкой. Кроме того, оно уже было использовано как название совсем другого языка. Знатоки семантики С находят, что С++ хуже, чем ++С. Язык не получил названия D, поскольку он является расширением С, и в нем не делается попыток решить какие-либо проблемы за счет отказа от возможностей С. Еще одну интересную интерпретацию названия С++ можно найти в приложении к [12].

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



В связи с лавинообразным процессом увеличения числа пользователей С++, пришлось сделать следующие изменения. Примерно в 1987 г. стало очевидно, что работа по стандартизации С++ неизбежна и что следует незамедлительно приступить к созданию основы для нее [22].  В результате были предприняты целенаправленные действия, чтобы установить контакт между разработчиками С++ и большинством пользователей.  Применялась обычная и электронная почта, а также было непосредственное общение на конференциях по С++ и других встречах.

Фирма AT&T Bell Laboratories внесла основной вклад в эту работу, предоставив автору право изучать версии справочного руководства по языку вместе с упоминавшимися разработчиками и пользователями.  Не следует недооценивать этот вклад, т.к. многие из них работают в компаниях, которые можно считать конкурентами фирмы AT&T.  Менее просвещенная компания могла бы просто ничего не делать, и в результате появилось бы несколько несогласованных версий языка.  Около ста представителей из порядка 20 организаций изучали и комментировали то, что стало современной версией справочного руководства и исходными материалами для ANSI по стандартизации С++. Их имена можно найти в "Аннотированном справочном руководстве по языку С++" [4].  Справочное руководство полностью вошло в настоящую книгу. Наконец, по инициативе фирмы Hewlett-Packard в декабре 1989 г. в составе ANSI был образован комитет X3J16. Ожидается, что работы по стандартизации С++ в ANSI (американский стандарт) станут составной частью работ по стандартизации силами ISO (Международной организации по стандартизации).

С++ развивался одновременно с развитием некоторых фундаментальных классов, представленных в данной книге. Например, автор разрабатывал классы complex, vector и stack, создавая одновременно возможность перегрузки операций.  В результате этих же усилий и благодаря содействию Д. Шапиро появились строковые и списочные классы. Эти классы стали первыми библиотечными классами, которые начали активно использоваться. Библиотека task, описываемая в [19] и в упражнении 13 из $$6.8 стала частью самой первой программы, написанной на языке "С с классами". Эта программа и используемые в ней классы были созданы для моделирования в стиле Симулы. Библиотека task была существенно переработана Д. Шапиро и продолжает активно использоваться до настоящего времени. Потоковая библиотека, как указывалось в первом издании книги, была разработана и применена автором. Д. Шварц преобразовал ее в потоковую библиотеку ввода-вывода ($$10), используя наряду с другими приемами метод манипуляторов Э.Кенига ($$10.4.2). Класс map ($$8.8) был предложен Э.Кенигом.  Он же создал класс Pool ($$13.10), чтобы использовать для библиотеки предложенный автором способ распределения памяти для классов ($$5.5.6). На создание остальных шаблонов повлияли шаблоны Vector, Map, Slist и sort, представленные в главе 8.

Итерация

В классе slist_base нет функций для просмотра списка, можно только вставлять и удалять элементы. Однако, в нем описывается как друг класс slist_base_iter, поэтому можно определить подходящий для списка итератор. Вот один из возможных, заданный в том стиле, какой был показан в $$7.8:

class slist_base_iter {

  slink* ce;                       // текущий элемент

  slist_base* cs;                  // текущий список

  public:

     inline slist_base_iter(slist_base& s);

     inline slink* operator()()

};

slist_base_iter::slist_base_iter(slist_base& s)

{

  cs = &s;

  ce = cs->last;

}

slink* slist_base_iter::operator()()

// возвращает 0, когда итерация кончается

{

  slink* ret = ce ? (ce=ce->next) : 0;

  if (ce == cs->last) ce = 0;

  return ret;

}

Исходя из этих определений, легко получить итераторы для Slist и Islist. Сначала надо определить дружественные классы для итераторов по соответствующим контейнерным классам:

template<class T> class Islist_iter;

template<class T> class Islist {

  friend class Islist_iter<T>;

  // ...

};

template<class T> class Slist_iter;

template<class T> class Slist {

  friend class Slist_iter<T>;

  // ...

};

Обратите внимание, что имена итераторов появляются без определения их шаблонного класса. Это способ определения в условиях взаимной зависимости шаблонов типа.

Теперь можно определить сами итераторы:

template<class T>

class Islist_iter : private slist_base_iter {

  public:

     Islist_iter(Islist<T>& s) : slist_base_iter(s) { }

     T* operator()()

       { return (T*) slist_base_iter::operator()(); }

};

template<class T>

class Slist_iter : private slist_base_iter {

  public:

     Slist_iter(Slist<T>& s) : slist_base_iter(s) { }

     inline T* operator()();

};

T* Slist_iter::operator()()

{

  return ((Tlink<T>*) slist_base_iter::operator()())->info;

}

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

void f(name* p)

{

  Islist<name> lst1;

  Slist<name> lst2;

  lst1.insert(p);

  lst2.insert(p);

  // ...

  Islist_iter<name> iter1(lst1);

  const name* p;

  while (p=iter1()) {

     list_iter<name> iter2(lst1);

     const name* q;

     while (q=iter2()) {

       if (p == q) cout << "найден" << *p << '\n';

     }

  }

}

Есть несколько способов задать итератор для контейнерного класса. Разработчик программы или библиотеки должен выбрать один из них и придерживаться его. Приведенный способ может показаться слишком хитрым. В более простом варианте можно было просто переименовать operator()() как next(). В обоих вариантах предполагается взаимосвязь между контейнерным классом и итератором для него, так что можно при выполнении итератора обработать случаи, когда элементы добавляются или удаляются из контейнера. Этот и некоторые другие способы задания итераторов были бы невозможны, если бы итератор зависел от функции пользователя, в которой есть указатели на элементы из контейнера. Как правило, контейнер или его итераторы реализуют понятие "установить итерацию на начало" и понятие "текущего элемента".

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

class slist_base {

  // ...

  slink* last;  // last->next голова списка

  slink* current;  // текущий элемент

  public:

     // ...

     slink* head() { return last?last->next:0; }

     slink* current() { return current; }

     void set_current(slink* p) { current = p; }

     slink* first() { set_current(head()); return current; }

     slink* next();

     slink* prev();

};

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

void f(Islist<name>& ilst)

// медленный поиск имен-дубликатов

{

  list_iter<name> slow(ilst);  // используется итератор

  name* p;

  while (p = slow()) {

     ilst.set_current(p); // рассчитываем на текущий элемент

     name* q;

     while (q = ilst.next())

       if (strcmp(p->string,q->string) == 0)

          cout << "дубликат" << p << '\n';

  }

}

Еще один вид итераторов показан в $$8.8.

Эффективность

Д. Кнуту принадлежит утверждение "Непродуманная оптимизация – корень

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

Лучший способ добиться эффективности - это создать ясный и простой проект. Только такой проект может остаться относительно устойчивым на весь период развития и послужить основой для настройки системы с целью повышения производительности. Здесь важно избежать "гаргантюализма", который является проклятием больших проектов. Слишком часто люди добавляют определенные возможности системы "на всякий случай" (см. $$11.3.3.2 и $$11.4.3), удваивая, учетверяя размер выполняемой программы ради завитушек. Еще хуже то, что такие усложненные системы трудно поддаются анализу, а по этому трудно отличить избыточные накладные расходы от необходимых и провести анализ и оптимизации на общем уровне. Оптимизация должна быть результатом анализа и оценки производительности системы, а не произвольным манипулированием с программным кодом, причем это особенно справедливо для больших систем, где интуиция разработчика или программиста не может служить надежным указателем в вопросах эффективности.

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

Эффективность и структура

Развитие языка С++ происходило на базе языка С, и, за небольшим исключением, С был сохранен в качестве подмножества C++. Базовый язык С был спроектирован таким образом, что имеется очень тесная связь между типами, операциями, операторами и объектами, с которыми непосредственно работает машина, т.е. числами, символами и адресами. За исключением операций new, delete и throw, а также проверяемого блока, для выполнения операторов и выражений С++ не требуется скрытой динамической аппаратной или программной поддержки.

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

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

В проекте С++ особое внимание уделяется структурированию программы.

Это вызвано увеличением размеров программ со времени появления С. Небольшую программу (скажем, не более 1000 строк) можно заставить из упрямства работать, нарушая все правила хорошего стиля программирования. Однако, действуя так, человек уже не сможет справиться с большой программой. Если у вашей программы в 10 000 строк плохая структура, то вы обнаружите, что новые ошибки появляются в ней так же быстро, как удаляются старые. С++ создавался с целью, чтобы большую программу можно было структурировать таким образом, чтобы одному человеку не пришлось работать с текстом в 25000 строк. В настоящее время можно считать, что эта цель полностью достигнута.

Существуют, конечно, программы еще большего размера. Однако те из них, которые действительно используются, обычно можно разбить на несколько практически независимых частей, каждая из которых имеет значительно меньший упомянутого размер. Естественно, трудность написания и сопровождения программы определяется не только числом строк текста, но и сложностью предметной области. Так что приведенные здесь числа, которыми обосновывались наши соображения, не надо воспринимать слишком серьезно.

К сожалению, не всякую часть программы можно хорошо структурировать,

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

Естественно, если С++ используется для большой программы, то это означает, что язык используют группы программистов. Полезную роль здесь сыграют свойственные языку модульность, гибкость и строго типизированныеинтерфейсы. В С++ есть такой же хороший набор средств для создания больших программ, как во многих языках.  Но когда программа становится еще больше, проблемы по ее созданию и сопровождению перемещаются из области языка в более глобальную область программных средств и управления проектом. Этим вопросам посвящены главы 11 и 12.

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

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

Экономия памяти

В процессе создания нетривиальной программы рано или поздно наступает

момент, когда требуется больше памяти, чем можно выделить или запросить. Есть два способа выжать еще некоторое количество памяти:

[1] паковать в байты переменные с малыми значениями;

[2] использовать одну и ту же память для хранения разных объектов в разное время.

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

Эксперимент и анализ

В начале честолюбивого проекта нам неизвестен лучший способ построения

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

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

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

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

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

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

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

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



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

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

Помимо экспериментов, предназначенных для оценки решений, принимаемых на этапе проектирования, источником получения полезной информации может быть анализ собственно проектирования и (или) реализации. Например, может оказаться полезным изучение различных зависимостей между классами (см.$$ 12.2), не следует забывать и о таких традиционных вспомогательных средствах реализации, как граф вызовов функций, оценка производительности и т.п.

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

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

Эквивалентность типов

Два структурных типа считаются различными даже тогда, когда они имеют

одни и те же члены. Например, ниже определены различные типы:

struct s1 { int a; };

struct s2 { int a; };

В результате имеем:

s1 x;

s2 y = x;                          // ошибка: несоответствие типов

Кроме того, структурные типы отличаются  от основных типов, поэтому  получим:

s1 x;

int i = x;                         // ошибка: несоответствие типов

Есть, однако, возможность, не определяя новый тип, задать новое имя для типа. В описании, начинающемся служебным словом typedef, описывается не переменная указанного типа, а вводится новое имя для типа. Приведем пример:

typedef char* Pchar;

Pchar p1, p2;

char* p3 = p1;

Это просто удобное средство сокращения записи.

Как создать библиотеку

Распространены такие обороты (и в этой книге тоже): "поместить в библиотеку", "поискать в такой-то библиотеке". Что они означают для программ на С++? К сожалению, ответ зависит от используемой системы. В этом разделе говорится о том, как создать и использовать библиотеку для десятой версии системы ЮНИКС. Другие системы должны предоставлять похожие возможности. Библиотека состоит из файлов .o, которые получаются в результате трансляции файлов .c. Обычно существует один или несколько файлов .h, в которых содержатся необходимые для вызова файлов .o описания. Рассмотрим в качестве примера, как для четко не оговоренного множества пользователей можно достаточно удобно определить некоторое множество стандартных математических функций. Заголовочный файл может иметь такой вид:

extern "C" {                       // стандартные математические функции

                                   // как правило написаны на С

  double sqrt(double); // подмножество <math.h>

  double sin(double);

  double cos(double);

  double exp(double);

  double log(double);

  // ...

}

Определения этих функций будут находиться в файлах sqrt.c, sin.c, cos.c, exp.c и log.c, соответственно.

Библиотеку с именем math.a можно создать с помощью таких команд:

$ CC -c sqrt.c sin.c cos.c exp.c log.c

$ ar cr math.a sqrt.o sin.o cos.o exp.o log.o

$ ranlib math.a

Здесь символ $ является приглашением системы.

Вначале транслируются исходные тексты, и получаются модули с теми же именами. Команда ar (архиватор) создает архив под именем math.a. Наконец, для быстрого доступа к функциям архив индексируется. Если в вашей системе нет команды ranlib (возможно она и не нужна), то, по крайней мере, можно найти в справочном руководстве ссылку на имя ar. Чтобы использовать библиотеку в своей программе, надо задать режим трансляции следующим образом:

$ CC myprog.c math.a

Встает вопрос: что дает нам библиотека math.a? Ведь можно было бы непосредственно использовать файлы .o, например так:

$ CC myprog.c sqrt.o sin.o cos.o exp.o log.o

Дело в том, что во многих случаях трудно правильно указать, какие файлы .o действительно нужны. В приведенной выше команде использовались все из них. Если же в myprog вызываются только sqrt() и cos(), тогда, видимо, достаточно задать такую команду:

$ CC myprog.c sqrt.o cos.o

Но это будет неверно, т.к. функция cos() вызывает sin().

Редактор связей, который вызывается командой CC для обработки файлов .a (в нашем случае для файла math.a), умеет из множества файлов, образующих библиотеку, извлекать только нужные файлы .o. Иными словами, связывание с библиотекой позволяет включать в программы много определений одного имени (в том числе определения функций и переменных, используемых только внутренними функциями, о которых пользователь никогда не узнает). В то же время в результирующую программу войдет только минимально необходимое число определений.

Как создать систему динамических запросов о типе

Здесь показано, как можно прямо реализовать динамические запросы о типе, когда в трансляторе таких возможностей нет. Это достаточно утомительная задача и можно пропустить этот раздел, так как в нем есть только детали конкретного решения.

Классы set и slist_set из $$13.3 следует изменить так, чтобы с ними могли работать операции запросов о типе. Прежде всего, в базовый класс set нужно ввести функции-члены, которые используют операции запросов о типе:

class set {

  public:

     static const Type_info info_obj;

     virtual typeid get_info() const;

     static typeid info();

     // ...

};

При выполнении программы единственным представителем объекта типа set является set::info_obj, который определяется так:

const Type_info set::info_obj("set",0);

С учетом этого определения функции тривиальны:

typeid set::get_info() const { return &info_obj; }

typeid set::info() { return &info_obj; }

typeid slist_set::get_info() const { return &info_obj; }

typeid slist_set::info() { return &info_obj; }

Виртуальная функция get_info() будет предоставлять операции ref_type_info() и ptr_type_info(), а статическая функция info() - операцию static_type_info().

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

Нужно несколько изменить класс slist_set:

class slist_set : public set, private slist {

  // ...

  public:

     static const Type_info info_obj;

     virtual typeid get_info() const;

     static typeid info();

     // ...

};

static const Type_info* slist_set_b[]

  = { &set::info_obj, &slist::info_obj, 0 };

const Type_info slist_set::info_obj("slist_set",slist_set_b);

typeid slist_set::get_info() const { return &info_obj; }

typeid slist_set::info() { return &info_obj; }

Калькулятор

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

r=2.5

area=pi*r*r

 (здесь pi имеет предопределенное значение). Тогда программа калькулятора

выдаст:

2.5

19.635

Результат вычислений для первой входной строки равен 2.5, а результат  для второй строки - это 19.635.

Программа калькулятора состоит из четырех основных частей: анализатора, функции ввода, таблицы имен и драйвера. По сути – это транслятор в миниатюре, в котором анализатор проводит синтаксический анализ, функция ввода обрабатывает входные данные и проводит лексический анализ, таблица имен хранит постоянную информацию, нужную для работы, а драйвер выполняет инициализацию, вывод результатов и обработку ошибок. К такому калькулятору можно добавить много других полезных возможностей, но программа его и так достаточно велика (200 строк), а введение новых возможностей только увеличит ее объем, не давая дополнительной информации для изучения С++.

Каркас области приложения

Мы перечислили виды классов, из которых можно создать библиотеки, нацеленные на проектирование и повторное использование прикладных программ. Они предоставляют определенные "строительные блоки" и объясняют как из них строить. Разработчик прикладного обеспечения создает каркас, в который должны вписаться универсальные строительные блоки. Задача проектирования прикладных программ может иметь иное, более обязывающее решение: написать программу, которая сама будет создавать общий каркас области приложения. Разработчик прикладного обеспечения в качестве строительных блоков будет встраивать в этот каркас прикладные программы. Классы, которые образуют каркас области приложения, имеют настолько обширный интерфейс, что их трудно назвать типами в обычном смысле слова. Они приближаются к тому пределу, когда становятся чисто прикладными классами, но при этом в них фактически есть только описания, а все действия задаются функциями, написанными прикладными программистами.

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

class filter {

  public:

     class Retry {

     public:

       virtual const char* message() { return 0; }

};

  virtual void start() { }

  virtual int retry() { return 2; }

  virtual int read() = 0;

  virtual void write() { }

  virtual void compute() { }

  virtual int result() = 0;

};

Нужные для производных классов функции описаны как чистые виртуальные, остальные функции просто пустые. Каркас содержит основной цикл обработки и зачаточные средства обработки ошибок:

int main_loop(filter* p)

{

  for (;;) {

     try {

       p->start();

       while (p->read()) {

          p->compute();

          p->write();

       }

       return p->result();

Класс ios

Большинство средств управления вводом-выводом сосредоточены в классе ios, который является базовым для ostream и istream. По сути здесь находится управление связью между istream или ostream и буфером, используемым для операций ввода-вывода. Именно  класс ios контролирует: как символы попадают в буфер и как они выбираются оттуда. Так, в классе ios есть член, содержащий информацию об используемой при чтении или записи целых чисел системы счисления (десятичная, восьмеричная или шестнадцатеричная), о  точности  вещественных чисел и т.п., а также функции для проверки и установки значений переменных, управляющих потоком.

class ios {

  //...

  public:

     ostream* tie(ostream* s);      // связать input и output

     ostream* tie();                // возвратить "tie"

     int width(int w);              // установить поле width

     int width() const;

     char fill(char);               // установить символ заполнения

     char fill() const;             // вернуть символ заполнения

     long flags(long f);

     long flags() const;

     long setf(long setbits, long field);

     long setf(long);

     long unsetf(long);

     int precision(int);            // установить точность для float

     int precision() const;

     int rdstate(); const;          // состояния потоков, см. $$10.3.2

     int eof() const;

     int fail() const;

     int bad() const;

     int good() const;

     void clear(int i=0);

     //...

};

В 10.3.2 описаны функции, работающие с состоянием потока, остальные

приведены ниже.

Класс Type_info

В классе Type_info есть минимальный объем информации для реализации операции ptr_cast(); его можно определить следующим образом:

class Type_info {

  const char* n;                   // имя

  const Type_info** b;             // список базовых классов

  public:

     Type_info(const char* name, const Type_info* base[]);

     const char* name() const;

     Base_iterator bases(int direct=0) const;

     int same(const Type_info* p) const;

     int has_base(const Type_info*, int direct=0) const;

     int can_cast(const Type_info* p) const;

     static const Type_info info_obj;

     virtual typeid get_info() const;

     static typeid info();

};

Две последние функции должны быть определены в каждом производном от Type_info классе.

Пользователь не должен заботиться о структуре объекта Type_info, и она приведена здесь только для полноты изложения. Строка, содержащая имя типа, введена для того, чтобы дать возможность поиска информации в таблицах имен, например, в таблице отладчика. С помощью нее а также информации из объекта Type_info можно выдавать более осмысленные диагностические сообщения. Кроме того, если возникнет потребность иметь несколько объектов типа Type_info, то имя может служить уникальным ключом этих объектов.

const char* Type_info::name() const

{

  return n;

}

int Type_info::same(const Type_info* p) const

{

  return this==p || strcmp(n,p->n)==0;

}

int Type_info::can_cast(const Type_info* p) const

{

  return same(p) || p->has_base(this);

}

Доступ к информации о базовых классах обеспечивается функциями bases() и has_base(). Функция bases() возвращает итератор, который порождает указатели на базовые классы объектов Type_info, а с помощью функции has_base() можно определить является ли заданный класс базовым для другого класса. Эти функции имеют необязательный параметр direct, который показывает, следует ли рассматривать все базовые классы (direct=0), или только прямые базовые классы (direct=1). Наконец, как описано ниже, с помощью функций get_info() и info() можно получить динамическую информацию о типе для самого класса Type_info.

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

Функция has_base() ищет базовые классы с помощью имеющегося в Type_info списка базовых классов. Хранить информацию о том, является ли базовый класс частным или виртуальным, не нужно, поскольку все ошибки, связанные с ограничениями доступа или неоднозначностью, будут выявлены при трансляции.

class base_iterator {

  short i;

  short alloc;

  const Type_info* b;

  public:

     const Type_info* operator() ();

     void reset() { i = 0; }

     base_iterator(const Type_info* bb, int direct=0);

     ~base_iterator() { if (alloc) delete[] (Type_info*)b; }

};

В следующем примере используется необязательный параметр для указания, следует ли рассматривать все базовые классы (direct==0) или только прямые базовые классы (direct==1).

base_iterator::base_iterator(const Type_info* bb, int direct)

{

  i = 0;

  if (direct) { // использование списка прямых базовых классов

     b = bb;

     alloc = 0;

     return;

  }

  // создание списка прямых базовых классов:

  // int n = число базовых

  b = new const Type_info*[n+1];

  // занести базовые классы в b

  alloc = 1;

  return;

}

const Type_info* base_iterator::operator() ()

{

  const Type_info* p = &b[i];

  if (p) i++;

  return p;

}

Теперь можно  задать операции запросов о типе с помощью макроопределений:

#define static_type_info(T)  T::info()

#define ptr_type_info(p)   ((p)->get_info())

#define ref_type_info(r)   ((r).get_info())

#define ptr_cast(T,p) \

  (T::info()->can_cast((p)->get_info()) ? (T*)(p) : 0)

#define ref_cast(T,r) \

  (T::info()->can_cast((r).get_info()) \

  ? 0 : throw Bad_cast(T::info()->name()), (T&)(r))

Предполагается, что тип особой ситуации Bad_cast (Ошибка_приведения) описан так:

class Bad_cast {

  const char* tn;

  // ...

  public:

  Bad_cast(const char* p) : tn(p) { }

  const char* cast_to() { return tn; }

  //  ...

};

В разделе $$4.7 было сказано, что появление макроопределений служит сигналом возникших проблем. Здесь проблема в том, что только транслятор имеет непосредственный доступ к литеральным типам, а макроопределения скрывают специфику реализации. По сути для хранения информации для динамических запросов о типах предназначена таблица виртуальных функций. Если реализация непосредственно поддерживает динамическую идентификацию типа, то рассматриваемые операции можно реализовать более естественно, эффективно и элегантно. В частности, очень просто реализовать функцию ptr_cast(), которая преобразует указатель на виртуальный базовый класс в указатель на его производные классы.

КЛАССЫ

"Эти типы не абстрактные, они столь же реальны, как int и float"

- Даг Макилрой

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

Классы и члены

Класс - это пользовательский тип. Этот раздел знакомит с основными средствами определения класса, создания его объектов, работы с такими объектами и, наконец, удаления этих объектов после использования.

Комментарии и расположение текста

Программу гораздо легче читать, и она становится намного понятнее, если разумно использовать комментарии и систематически выделять текст программы пробелами. Есть несколько способов расположения текста программы, но нет причин считать, что один из них - наилучший. Хотя у каждого свой вкус. То же можно сказать и о комментариях.

Однако можно заполнить программу такими комментариями, что читать и понимать ее будет только труднее. Транслятор не в силах понять комментарий, поэтому он не может убедиться в том, что комментарий:

 [1] осмысленный,

 [2] действительно описывает программу,

 [3] не устарел.

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

Если некий факт можно прямо выразить в языке, то так и следует  делать, и не надо считать, что достаточно упомянуть его в комментарии. Последнее замечание относится к комментариям, подобным приведенным ниже:

// переменную "v" необходимо инициализировать.

// переменная "v" может использоваться только в функции "f()".

// до вызова любой функции из этого файла

// необходимо вызвать функцию "init()".

// в конце своей программы вызовите функцию "cleanup()".

// не используйте функцию "weird()".

// функция "f()" имеет два параметра.

При правильном программировании на С++ такие комментарии обычно оказываются излишними. Чтобы именно эти комментарии стали ненужными, можно воспользоваться правилами связывания ($$4.2) и областей видимости, а также правилами инициализации и уничтожения объектов класса ($$5.5).

Если некоторое утверждение выражается самой программой, не нужно повторять его в комментарии. Например:

a = b + c;                         // a  принимает значение b+c

count++;                           // увеличим счетчик count

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

Можно рекомендовать такой стиль введения комментариев в программу:
[1]    начинать с комментария каждый файл программы: указать в общих чертах, что в ней определяется, дать ссылки на справочные руководства, общие идеи по сопровождению программы и т.д.;
[2]    снабжать комментарием каждое определение класса или шаблона типа;
[3]    комментировать каждую нетривиальную функцию, указав: ее назначение, используемый алгоритм (если только он неочевиден) и, возможно, предположения об окружении, в котором работает функция;
[4]    комментировать определение каждой глобальной переменной;
[5]    давать некоторое число комментариев в тех местах, где алгоритм неочевиден или непереносим;
[6]    больше практически ничего.
Приведем пример:
//  tbl.c: Реализация таблицы имен.
/*
  Использован метод Гаусса
  см. Ральстон "Начальный курс по ..." стр. 411.
*/
// в swap() предполагается, что стек AT&T начинается с 3B20.
/************************************
  Авторские права (c) 1991 AT&T, Inc
  Все права сохранены
**************************************/
Правильно подобранные и хорошо составленные комментарии играют в программе важную роль. Написать хорошие комментарии не менее трудно, чем саму программу, и это - искусство, в котором стоит совершенствоваться.
Заметим, что если в функции используются только комментарии вида //, то любую ее часть можно сделать комментарием с помощью /* */, и наоборот.

Компоненты

В языке С++ нет конструкций, которые могут выразить прямо в программе

понятие компонента, т.е. множества связанных классов. Основная причина этого в том, что множество классов (возможно с соответствующими глобальными функциями и т.п.) может соединяться в компонент по самым разным признакам. Отсутствие явного представления понятия в языке затрудняет проведение границы между информацией (имена), используемой внутри компонента, и информацией (имена), передаваемой из компонента пользователям. В идеале, компонент определяется множеством интерфейсов, используемых для его реализации, плюс множеством интерфейсов, представляемых пользователем, а все прочее считается "спецификой реализации" и должно быть скрыто от остальных частей системы. Таково может быть в действительности представление о компоненте у разработчика. Программист должен смириться с тем фактом, что С++ не дает общего понятия пространства имен компонента, так что его приходится "моделировать" с помощью понятий классов и единиц трансляции, т.е. тех средств, которые есть в С++ для ограничения области действия нелокальных имен.

Рассмотрим два класса, которые должны совместно использовать функцию f() и переменную v. Проще всего описать f и v как глобальные имена. Однако, всякий опытный программист знает, что такое "засорение" пространства имен может привести в конце концов к неприятностям: кто-то может ненарочно использовать имена f или v не по назначению или нарочно обратиться  к f или v, прямо используя "специфику реализации" и обойдя тем самым явный интерфейс компонента. Здесь возможны три решения:

[1]        Дать "необычные" имена объектам и функциям, которые не рассчитаны на пользователя.

[2]        Объекты или функции, не предназначенные для пользователя, описать в одном из файлов программы как статические (static).

[3]        Поместить объекты и функции, не предназначенные для пользователя, в класс, определение которого закрыто для пользователей.

Первое решение примитивно и достаточно неудобно для создателя программы, но оно действует:

// не используйте специфику реализации compX,

// если только вы не разработчик compX:

extern void compX_f(T2*, const char*);

extern T3 compX_v;

// ...

Такие имена как compX_f и compX_v вряд ли могут привести к коллизии, а на

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

// специфика реализации compX:

static void compX_f(T2* a1, const char *a2) { /* ... */ }

static T3 compX_v;

// ...

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

class compX_details {  // специфика реализации compX

  public:

     static void f(T2*, const char*);

     static T3 v;

     // ...

};

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

В компоненте конечно может быть много классов, не предназначенных для общего пользования. Если их имена тоже рассчитаны только на локальное использование, то их также можно "спрятать" внутри классов, содержащих специфику реализации:

class compX_details { // специфика реализации compX.

  public:

     // ...

     class widget {

       // ...

     };

     // ...

};

Укажем, что вложенность создает барьер для использования widget в других частях программы. Обычно классы, представляющие ясные понятия, считаются первыми кандидатами на повторное использование, и, значит составляют часть интерфейса компонента, а не деталь реализации. Другими словами, хотя для сохранения надлежащего уровня абстракции вложенные объекты, используемые для представления некоторого объекта класса, лучше считать скрытыми деталями реализации, классы, определяющие такие вложенные объекты, лучше не делать скрытыми, если они имеют достаточную общность. Так, в следующем примере упрятывание, пожалуй, излишне:



class Car {

  class Wheel {

     // ...

  };

  Wheel flw, frw, rlw, rrw;

  // ...

};

Во многих ситуациях для поддержания уровня абстракции понятия машины (Car) следует упрятывать реальные колеса (класс Wheel), ведь когда вы работаете с машиной, вы не можете независимо от нее использовать колеса. С другой стороны, сам класс Wheel является вполне подходящим для широкого использования, поэтому лучше вынести его определение из класса Car:

class Wheel {

  // ...

};

class Car {

  Wheel flw, frw, rlw, rrw;

  // ...

};

Использовать ли вложенность? Ответ на этот вопрос зависит от целей проекта и общности используемых понятий. Как вложенность, так и ее отсутствие могут быть вполне допустимыми решениями для данного проекта. Но поскольку вложенность предохраняет от засорения общего пространства имен, в своде правил ниже рекомендуется использовать вложенность, если только нет причин не делать этого.

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

Другим средством построения компонента и представления его пользователю служит иерархия. Тогда базовый класс используется как хранилище общих данных и функций. Таким способом устраняется проблема, связанная с глобальными данными и функциями, предназначенными для реализации общих запросов классов данного компонента. С другой стороны, при таком решении классы компонента становятся слишком связанными друг с другом, а пользователь попадает в зависимость от всех базовых классов тех компонентов, которые ему действительно нужны. Здесь также проявляется тенденция к тому, что члены, представляющие "полезные" функции и данные "всплывают"  к базовому классу, так что при слишком большой иерархии классов проблемы с глобальными данными и функциями проявятся уже в рамках этой иерархии. Вероятнее всего, это произойдет для иерархии с одним корнем, а для борьбы с этим явлением можно применять виртуальные базовые классы ($$6.5.4). Иногда лучше выбрать иерархию для представления компонента, а иногда нет. Как всегда сделать выбор предстоит разработчику.

Конкретные типы

Такие классы как vector ($$1.4), Slist ($$8.3), date ($$5.2.2) и complex ($$7.3) являются конкретными в том смысле, что каждый из них представляет довольно простое понятие и обладает необходимым набором операций. Имеется взаимнооднозначное соответствие между интерфейсом класса и его реализацией. Ни один из них  (изначально) не предназначался в качестве базового для получения производных классов. Обычно в иерархии классов конкретные типы стоят особняком. Каждый конкретный тип можно понять изолированно, вне связи с другими классами. Если реализация конкретного типа удачна, то работающие с ним программы сравнимы по размеру и скорости со сделанными вручную программами, в которых используется некоторая специальная версия общего понятия. Далее, если произошло значительное изменение реализации, обычно модифицируется и интерфейс, чтобы отразить эти изменения. Интерфейс, по своей сути, обязан показать какие изменения оказались существенными в данном контексте. Интерфейс более высокого уровня оставляет больше свободы для изменения реализации, но может ухудшить характеристики программы. Более того, хорошая реализация зависит только от минимального числа действительно существенных классов. Любой из этих классов можно использовать без накладных расходов, возникающих на этапе трансляции или выполнения, и вызванных приспособлением к другим, "сходным" классам программы.    Подводя итог, можно указать такие условия, которым должен удовлетворять конкретный тип:

[1]        полностью отражать данное понятие и метод его реализации;

[2]        с помощью подстановок и операций, полностью использующих полезные свойства понятия и его реализации, обеспечивать эффективность по скорости и памяти, сравнимую с "ручными программами";

[3]        иметь минимальную зависимость от других классов;

[4]        быть понятным и полезным даже изолированно.

Все это должно привести к тесной связи между пользователем и программой, реализующей конкретный тип. Если в реализации произошли изменения, программу пользователя придется перетранслировать, поскольку в ней наверняка содержатся вызовы функций, реализуемые подстановкой, а также локальные переменные конкретного типа.

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

Название "конкретный тип" (CDT - concrete data type, т.е. конкретный тип данных) , было выбрано по контрасту с термином "абстрактный тип" (ADT - abstract data type, т.е. абстрактный тип данных). Отношения между CDT и ADT обсуждаются в $$13.3.

Существенно, что конкретные типы не предназначены для явного выражения некоторой общности. Так, типы slist и vector можно использовать в качестве альтернативной реализации понятия множества, но в языке это явно не отражается. Поэтому, если программист хочет работать с множеством, использует конкретные типы и не имеет определения класса множество, то он должен выбирать между типами slist и vector. Тогда программа записывается в терминах выбранного класса, скажем, slist, и если потом предпочтут использовать другой класс, программу придется переписывать.

Это потенциальное неудобство компенсируется наличием всех "естественных" для данного класса операций, например таких, как индексация для массива и удаление элемента для списка. Эти операции представлены в оптимальном варианте, без "неестественных" операций типа индексации списка или удаления массива, что могло бы вызвать путаницу. Приведем пример:



void my(slist& sl)

{

  for (T* p = sl.first(); p; p = sl.next())

  {

     // мой код

  }

  // ...

}

void your(vector& v)

{

  for (int i = 0; i<v.size(); i++)

  {

     // ваш код

  }

  // ...

}

Существование таких "естественных" для выбранного метода реализации операций обеспечивает эффективность программы и значительно облегчает ее написание. К тому же, хотя реализация вызова подстановкой обычно возможна только для простых операций типа индексации массива или получения следующего элемента списка, она оказывает значительный эффект на скорость выполнения программы. Загвоздка здесь состоит в том, что фрагменты программы, использующие по своей сути эквивалентные операции, как, например, два приведенных выше цикла, могут выглядеть непохожими друг на друга, а фрагменты программы, в которых для эквивалентных операций используются разные конкретные типы, не могу заменять друг друга. Обычно, вообще, невозможно свести сходные фрагменты программы в один.

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

void user()

{

  slist sl;

  vector v(100);

  my(sl);

  your(v);

  my(v);                           // ошибка: несоответствие типа

  your(sl);                        // ошибка: несоответствие типа

}

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

void my(slist&);

void my(vector&);

void your(slist&);

void your(vector&);

void user()

{

  slist sl;

  vector v(100);

  my(sl);

  your(v);

  my(v);                           // теперь нормально: вызов my(vector&)

  your(sl);                        // теперь нормально: вызов your(slist&)

}

Поскольку тело функции существенно зависит от типа ее параметра, надо написать каждую версию функций my() и your() независимо друг от друга, что может быть хлопотно.

С учетом всего изложенного конкретный тип, можно сказать, походит на встроенные типы. Положительной стороной этого является тесная связь между пользователем типа и его создателем, а также между пользователями, которые создают объекты данного типа, и пользователями, которые пишут функции, работающие с этими объектами. Чтобы правильно использовать конкретный тип, пользователь должен разбираться в нем детально. Обычно не существует каких-то универсальных свойств, которыми обладали бы все конкретные типы библиотеки, и что позволило бы пользователю, рассчитывая на эти свойства, не тратить силы на изучение отдельных классов. Такова плата за компактность программы и эффективность ее выполнения. Иногда это вполне разумная плата, иногда нет. Кроме того, возможен такой случай, когда отдельный конкретный класс проще понять и использовать, чем более общий (абстрактный) класс. Именно так бывает с классами, представляющими хорошо известные типы данных, такие как массивы или списки.

Тем не менее, укажем, что в идеале надо скрывать, насколько возможно, детали реализации, пока это не ухудшает характеристики программы. Большую помощь здесь оказывают функции-подстановки. Если сделать открытыми переменные, являющиеся членами, с помощью описания public, или непосредственно работать с ними с помощью функций, которые устанавливают и получают значения этих переменных, то почти всегда это приводит к плохому результату. Конкретные типы должны быть все-таки настоящими типами, а не просто программной кучей с нескольким функциями, добавленными ради удобства.

Константы с плавающей точкой

Константы с плавающей точкой имеют тип double. Транслятор должен  предупреждать о таких константах, значение которых не укладывается в  формат, выбранный для представления чисел с плавающей точкой. Приведем  примеры констант с плавающей точкой:

1.23    .23      0.23     1.    1.0     1.2e10    1.23e-15

Отметим, что внутри константы с плавающей точкой не должно быть пробелов. Например, 65.43  e-21 не является константой с плавающей точкой, транслятор распознает это как четыре отдельные лексемы:

65.43    e    -    21

что вызовет синтаксическую ошибку. Если нужна константа с плавающей точкой типа float, то ее можно получить, используя окончание f:

3.14159265f     2.0f     2.997925f

Конструкторы

Вместо того, чтобы описывать несколько функций, можно описать конструктор, который из параметра double создает complex:

class complex {

  // ...

  complex(double r) { re=r; im=0; }

};

Этим определяется как получить complex, если задан double. Это традиционный способ расширения вещественной прямой до комплексной плоскости.

Конструктор с единственным параметром не обязательно вызывать явно:

complex z1 = complex(23);

complex z2 = 23;

Обе переменные z1 и z2 будут инициализироваться вызовом complex(23).

Конструктор является алгоритмом создания значения заданного типа. Если требуется значение некоторого типа и существует строящий его конструктор, параметром которого является это значение, то тогда этот конструктор и будет использоваться. Так, класс complex можно было описать следующим образом:

class complex {

  double re, im;

  public:

     complex(double r, double i =0) {  re=r; im=i; }

     friend complex operator+(complex, complex);

     friend complex operator*(complex, complex);

     complex operator+=(complex);

     complex operator*=(complex);

     // ...

};

Все операции над комплексными переменными и целыми константами с учетом этого описания становятся законными. Целая константа будет интерпретироваться как комплексное число с мнимой частью, равной нулю. Так, a=b*2 означает

a = operator*(b, complex( double(2), double(0) ) )

Новые версии операций таких, как + , имеет смысл определять только, если практика покажет, что повышение эффективности за счет отказа от преобразований типа стоит того. Например, если выяснится, что операция умножения комплексной переменной на вещественную константу является критичной, то к множеству операций можно добавить operator*=(double):

class complex {

  double re, im;

  public:

     complex(double r, double i =0) { re=r; im=i; }

     friend complex operator+(complex, complex);

     friend complex operator*(complex, complex);

     complex& operator+=(complex);

     complex& operator*=(complex);

     complex& operator*=(double);

     // ...

};

Операции присваивания типа *= и += могут быть очень полезными для работы с пользовательскими типами, поскольку обычно запись с ними короче, чем с их обычными "двойниками" * и + , а кроме того они могут повысить скорость выполнения программы за счет исключения временных переменных:

inline complex& complex::operator+=(complex a)

{

  re += a.re;

  im += a.im;

  return *this;

}

При использовании этой функции не требуется временной переменной для хранения результата, и она достаточно проста, чтобы транслятор мог "идеально" произвести подстановку тела. Такие простые операции  как сложение комплексных тоже легко задать непосредственно:

inline complex operator+(complex a, complex b)

{

  return complex(a.re+b.re, a.im+b.im);

}

Здесь в операторе return используется конструктор, что дает транслятору

ценную подсказку на предмет оптимизации. Но для более сложных типов и операций, например таких, как умножение матриц, результат нельзя задать как одно выражение, тогда операции * и + проще реализовать с помощью *= и += , и они будут легче поддаваться оптимизации:

matrix& matrix::operator*=(const matrix& a)

{

  // ...

  return *this;

}

matrix operator*(const matrix& a, const matrix& b)

{

  matrix prod = a;

  prod *= b;

  return prod;

}

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

Пользовательское преобразование типа применяется только в том случае, если оно единственное($$7.3.3).

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

Конструкторы и деструкторы

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

[1]    автоматический, который создается каждый раз, когда его описание встречается при выполнении программы, и уничтожается по выходе из блока, в котором он описан;

[2]    статический, который создается один раз при запуске программы и уничтожается при ее завершении;

[3]    объект в свободной памяти, который создается операцией new и уничтожается операцией delete;

[4]    объект-член, который создается в процессе создания другого класса или при создании массива, элементом которого он является.

 Кроме этого объект может создаваться, если в выражении явно используется его конструктор ($$7.3) или как временный объект ($$R.12.2). В обоих случаях такой объект не имеет имени. В следующих подразделах предполагается, что объекты относятся к классу с конструктором и деструктором. В качестве примера используется класс table из $$5.3.1.

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

Допустим, что у нас нет бесконечной памяти и сборщика мусора. На какие средства управления памятью может рассчитывать создатель контейнера, например, класса 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; }

  }

};

Контроль доступа

Член класса может быть частным (private), защищенным (protected) или общим (public):

Частный член класса X могут использовать только функции-члены и друзья класса X.

Защищенный член класса X могут использовать только функции-члены и друзья класса X, а так же функции-члены и друзья всех

производных от X классов (см. $$5.4.1).

Общий член можно использовать в любой функции.

Эти правила соответствуют делению обращающихся к классу функций на три вида: функции, реализующие класс (его друзья и члены), функции, реализующие производный класс (друзья и члены производного класса) и все остальные функции.

Контроль доступа применяется единообразно ко всем именам. На контроль доступа не влияет, какую именно сущность обозначает имя. Это означает, что частными могут быть функции-члены, константы и т.д. наравне с частными членами, представляющими данные:

class X {

  private:

     enum { A, B };

     void f(int);

     int a;

};

void X::f(int i)

{

  if (i<A) f(i+B);

  a++;

}

void g(X& x)

{

  int i = X::A;     // ошибка: X::A частный член

  x.f(2);           // ошибка: X::f частный член

  x.a++;            // ошибка: X::a частный член

}

Косвенное обращение

Операцию косвенного обращения к члену -> можно определить как унарную постфиксную операцию. Это значит, если есть класс

class Ptr {

  // ...

  X* operator->();

};

объекты класса Ptr могут использоваться для доступа к членам класса X также, как для этой цели используются указатели:

void f(Ptr p)

{

  p->m = 7;                        // (p.operator->())->m = 7

}

Превращение объекта p в указатель p.operator->() никак не зависит от члена m, на который он указывает. Именно по этой причине operator->() является унарной постфиксной операцией. Однако, мы не вводим новых синтаксических обозначений, так что имя члена по-прежнему должно идти после -> :

void g(Ptr p)

{

  X* q1 = p->;                     // синтаксическая ошибка

  X* q2 = p.operator->();          // нормально

}

Перегрузка операции -> прежде всего используется для создания "хитрых указателей", т.е. объектов, которые помимо использования как указатели позволяют проводить некоторые операции при каждом обращении к указуемому объекту с их помощью. Например, можно определить класс RecPtr для организации доступа к объектам класса Rec, хранимым на диске. Параметром конструктора RecPtr является имя, которое будет использоваться для поиска объекта на диске. При обращении к объекту с помощью функции RecPtr::operator->() он переписывается в основную память, а в конце работы деструктор RecPtr записывает измененный объект обратно на диск.

class RecPtr {

  Rec* in_core_address;

  const char* identifier;

  // ...

  public:

     RecPtr(const char* p)

       : identifier(p) { in_core_address = 0; }

     ~RecPtr()

       { write_to_disc(in_core_address,identifier); }

     Rec* operator->();

};

Rec* RecPtr::operator->()

{

  if (in_core_address == 0)

     in_core_address = read_from_disc(identifier);

  return in_core_address;

}

Использовать это можно так:

main(int argc, const char* argv)

{

  for (int i = argc; i; i--) {

     RecPtr p(argv[i]);

     p->update();

  }

}

На самом деле, тип RecPtr должен определяться как шаблон типа (см. $$8), а тип структуры Record будет его параметром. Кроме того, настоящая программа будет содержать обработку ошибок и взаимодействие с диском будет организовано не столь примитивно.

Для обычных указателей операция -> эквивалентна операциям, использующим * и []. Так, если описано

Y* p;

то выполняется соотношение

p->m == (*p).m == p[0].m

Как всегда, для определенных пользователем операций такие соотношения

не гарантируются. Там, где все-таки такая эквивалентность требуется, ее можно обеспечить:

class X {

  Y* p;

  public:

     Y* operator->() { return p; }

     Y& operator*() { return *p; }

     Y& operator[](int i) { return p[i]; }

};

Если в вашем классе определено более одной подобной операции, разумно будет обеспечить эквивалентность, точно так же, как разумно предусмотреть для простой переменной x некоторого класса, в котором есть операции ++, += = и +, чтобы операции ++x и x+=1 были эквивалентны x=x+1.

Перегрузка -> как и перегрузка [] может играть важную роль для целого класса настоящих программ, а не является просто экспериментом ради любопытства. Дело в том, что в программировании понятие косвенности является ключевым, а перегрузка -> дает ясный, прямой эффективный способ представления этого понятия в программе. Есть другая точка зрения на операцию ->, как на средство задать в С++ ограниченный, но полезный вариант понятия делегирования (см. $$12.2.8 и 13.9).

---

---