- •Глава 6 посвящена понятию производных классов, которое позволяет строить
- •Раздел 3.4 главы 2. Для обозначения справочного руководства применяется
- •1991 Г.Г. (такие как множественное наследование, статические функции-члены
- •1.1 Введение
- •1.2 Парадигмы программирования
- •1.2.1 Процедурное программирование
- •1.2.5 Объектно-ориентированное программирование
- •1.5 Поддержка объектно-ориентированного программирования
- •1.5.1 Механизм вызова
- •1.5.2 Проверка типа
- •1.5.3 Множественное наследование
- •1.6 Пределы совершенства
- •2.2 Имена
- •2.3.2 Неявное преобразование типа
- •2.4 Литералы
- •2.4.4 Строки
- •2.6. Экономия памяти
- •2.6.1 Поля
- •3.1.1 Анализатор
- •3.1.2 Функция ввода
- •3.2 Сводка операций
- •3.2.3 Инкремент и декремент
- •3.2.5 Преобразование типа
- •3.2.6 Свободная память
- •3.3.2 Оператор goto
- •4.1 Введение
- •4.3.1 Единственный заголовочный файл
- •4.3.2 Множественные заголовочные файлы
- •4.4 Связывание с программами на других языках
- •4.6.3 Передача параметров
- •5.1 Введение и краткий обзор
- •5.3.1 Альтернативные реализации
- •5.3.2 Законченный пример класса
- •Vector и matrix, мы могли бы обойтись без контроля индекса при
- •5.4.5 Указатели на члены
- •5.4.6 Структуры и объединения
- •5.5.3 Свободная память
- •5.5.5 Массивы объектов класса
- •6.1 Введение и краткий обзор
- •6.2.3 Иерархия классов
- •6.2.4 Поля типа
- •6.4.1 Монитор экрана
- •6.5 Множественное наследование
- •7.1 Введение
- •7.3 Пользовательские операции преобразования типа
- •7.3.2 Операции преобразования
- •7.3.3 Неоднозначности
- •7.5 Большие объекты
- •Void f2(t a) // вариант с контролем
- •Void f3(t a) // вариант с контролем
- •Inv() обращает саму матрицу m, а не возвращает новую, обратную m,
- •7.13 Предостережения
- •8.1 Введение
- •8.4.4 Неявная передача операций
- •8.4.5 Введение операций с помощью параметров шаблонного класса
- •8.7.1 Задание реализации с помощью параметров шаблона
- •9.1 Обработка ошибок
- •9.1.2 Другие точки зрения на особые ситуации
- •9.3.2 Производные особые ситуации
- •9.4.2 Предостережения
- •9.4.3 Исчерпание ресурса
- •9.4.4 Особые ситуации и конструкторы
- •9.5 Особые ситуации могут не быть ошибками
- •10.1 Введение
- •10.2 Вывод
- •10.2.1 Вывод встроенных типов
- •10.4.1.2 Поля вывода
- •10.4.1.4 Вывод целых
- •Istream - шаблон типа smanip, а smanip - двойник для ioss.
- •10.5.1 Закрытие потоков
- •10.5.2 Строковые потоки
- •X Целый параметр выдается в шестнадцатеричной записи;
- •11.1 Введение
- •11.2 Цели и средства
- •11.3 Процесс развития
- •11.3.1 Цикл развития
- •11.3.2 Цели проектирования
- •11.3.3 Шаги проектирования
- •11.3.3.1 Шаг 1: определение классов
- •11.3.3.2 Шаг 2: определение набора операций
- •11.3.3.3 Шаг 3: указание зависимостей
- •11.3.3.4 Шаг 4: определение интерфейсов
- •11.3.3.5 Перестройка иерархии классов
- •11.3.3.6 Использование моделей
- •11.3.4 Эксперимент и анализ
- •11.3.5 Тестирование
- •11.3.6 Сопровождение
- •11.3.7 Эффективность
- •11.4 Управление проектом
- •11.4.1 Повторное использование
- •11.4.2 Размер
- •11.4.3 Человеческий фактор
- •11.5 Свод правил
- •11.6 Список литературы с комментариями
- •12.1 Проектирование и язык программирования.
- •12.1.1 Игнорирование классов
- •12.1.2 Игнорирование наследования
- •12.1.3 Игнорирование статического контроля типов
- •12.1.4 Гибридный проект
- •12.2 Классы
- •12.2.1 Что представляют классы?
- •12.2.2 Иерархии классов
- •12.2.3 Зависимости в рамках иерархии классов.
- •Vertical_scrollbar или с помощью одного типа scrollbar, который
- •12.2.6 Отношения использования
- •12.2.7 Отношения внутри класса
- •12.3 Компоненты
- •12.4 Интерфейсы и реализации
- •12.5 Свод правил
- •13.1 Введение
- •13.2 Конкретные типы
- •13.4 Узловые классы
- •1, 2, 6 И 7. Класс, который не удовлетворяет условию 6, походит
- •13.5.1 Информация о типе
- •13.6 Обширный интерфейс
- •13.7 Каркас области приложения
- •13.8 Интерфейсные классы
- •13.10 Управление памятью
4.1 Введение
Роль файла в языке С++ сводится к тому, что он определяет файловую
область видимости ($$R.3.2). Это область видимости глобальных
функций (как статических, так и подстановок), а также глобальных
переменных (как статических, так и со спецификацией const). Кроме
того, файл является традиционной единицей хранения в системе, а
также единицей трансляции. Обычно системы хранят, транслируют и
представляют пользователю программу на С++ как множество файлов,
хотя существуют системы, устроенные иначе. В этой главе будет
обсуждаться в основном традиционное использование файлов.
Всю программу поместить в один файл, как правило, невозможно,
поскольку программы стандартных функций и программы операционной
системы нельзя включить в текстовом виде в программу пользователя.
Вообще, помещать всю программу пользователя в один файл обычно
неудобно и непрактично. Разбиения программы на файлы может
облегчить понимание общей структуры программы и дает транслятору
возможность поддерживать эту структуру. Если единицей трансляции
является файл, то даже при небольшом изменении в нем следует
его перетранслировать. Даже для программ не слишком большого
размера время на перетрансляцию можно значительно сократить, если
ее разбить на файлы подходящего размера.
Вернемся к примеру с калькулятором. Решение было дано в виде
одного файла. Когда вы попытаетесь его транслировать, неизбежно
возникнут некоторые проблемы с порядком описаний. По крайней мере
одно "ненастоящее" описание придется добавить к тексту, чтобы
транслятор мог разобраться в использующих друг друга функциях
expr(), term() и prim(). По тексту программы видно, что она
состоит из четырех частей: лексический анализатор (сканер),
собственно анализатор, таблица имен и драйвер. Однако, этот факт
никак не отражен в самой программе. На самом деле калькулятор
не был запрограммирован именно так. Так не следует писать
программу. Даже если не учитывать все рекомендации по
программированию, сопровождению и оптимизации для такой "зряшной"
программы, все равно ее следует создавать из нескольких файлов
хотя бы для удобства.
Чтобы раздельная трансляция стала возможной, программист
должен предусмотреть описания, из которых транслятор получит
достаточно сведений о типах для трансляции файла, составляющего
только часть программы. Требование непротиворечивости использования
всех имен и типов для программы, состоящей из нескольких раздельно
транслируемых частей, так же справедливо, как и для программы,
состоящей из одного файла. Это возможно только в том случае, когда
описания, находящиеся в разных единицах трансляции, будут
согласованы. В вашей системе программирования имеются средства,
которые способны установить, выполняется ли это. В частности, многие
противоречия обнаруживает редактор связей. Редактор связей - это программа,
которая связывает по именам раздельно транслируемые части программы.
Иногда его по ошибке называют загрузчиком.
4.2 Связывание
Если явно не определено иначе, то имя, не являющееся локальным для
некоторой функции или класса, должно обозначать один и тот же тип,
значение, функцию или объект во всех единицах трансляции данной
программы. Иными словами, в программе может быть только один
нелокальный тип, значение, функция или объект с данным именем.
Рассмотрим для примера два файла:
// file1.c
int a = 1;
int f() { /* какие-то операторы */ }
// file2.c
extern int a;
int f();
void g() { a = f(); }
В функции g() используются те самые a и f(), которые определены в
файле file1.c. Служебное слово extern показывает, что описание
a в файле file2.c является только описанием, но не определением.
Если бы присутствовала инициализация a, то extern просто
проигнорировалось бы, поскольку описание с инициализацией всегда
считается определением. Любой объект в программе может определяться
только один раз. Описываться же он может неоднократно, но все
описания должны быть согласованы по типу. Например:
// file1.c:
int a = 1;
int b = 1;
extern int c;
// file2.c:
int a;
extern double b;
extern int c;
Здесь содержится три ошибки: переменная a определена дважды ("int a;"
- это определение, означающее "int a=0;"); b описано дважды, причем
с разными типами; c описано дважды, но неопределено. Такие ошибки
(ошибки связывания) транслятор, который обрабатывает файлы
по отдельности, обнаружить не может, но большая их часть
обнаруживается редактором связей.
Следующая программа допустима в С, но не в С++:
// file1.c:
int a;
int f() { return a; }
// file2.c:
int a;
int g() { return f(); }
Во-первых, ошибкой является вызов f() в file2.c, поскольку в этом
файле f() не описана. Во-вторых, файлы программы не могут быть
правильно связаны, поскольку a определено дважды.
Если имя описано как static, оно становится локальном в этом
файле. Например:
// file1.c:
static int a = 6;
static int f() { /* ... */ }
// file2.c:
static int a = 7;
static int f() { /* ... */ }
Приведенная программа правильна, поскольку a и f определены как
статические. В каждом файле своя переменная a и функция f().
Если переменные и функции в данной части программы описаны как
static, то в этой части программы проще разобраться, поскольку не нужно
заглядывать в другие части. Описывать функции как статические
полезно еще и по той причине, что транслятору предоставляется
возможность создать более простой вариант операции вызова функции.
Если имя объекта или функции локально в данном файле, то говорят,
что объект подлежит внутреннему связыванию. Обратно, если имя
объекта или функции нелокально в данном файле, то он подлежит
внешнему связыванию.
Обычно говорят, что имена типов, т.е. классов и перечислений,
не подлежат связыванию. Имена глобальных классов и перечислений
должны быть уникальными во всей программе и иметь единственное
определение. Поэтому, если есть два даже идентичных определения
одного класса, это - все равно ошибка:
// file1.c:
struct S { int a; char b; };
extern void f(S*);
// file2.c:
struct S { int a; char b; };
void f(S* p) { /* ... */ }
Но будьте осторожны: опознать идентичность двух описаний класса
не в состоянии большинство систем программирования С++. Такое
дублирование может вызвать довольно тонкие ошибки (ведь классы
в разных файлах будут считаться различными).
Глобальные функции-подстановки подлежат внутреннему связыванию,
и то же по умолчанию справедливо для констант. Синонимы типов,
т.е. имена typedef, локальны в своем файле, поэтому описания
в двух данных ниже файлах не противоречат друг другу:
// file1.c:
typedef int T;
const int a = 7;
inline T f(int i) { return i+a; }
// file2.c:
typedef void T;
const int a = 8;
inline T f(double d) { cout<<d; }
Константа может получить внешнее связывание только с помощью явного
описания:
// file3.c:
extern const int a;
const int a = 77;
// file4.c:
extern const int a;
void g() { cout<<a; }
В этом примере g() напечатает 77.
4.3 Заголовочные файлы
Типы одного объекта или функции должны быть согласованы во всех их
описаниях. Должен быть согласован по типам и входной текст,
обрабатываемый транслятором, и связываемые части программы. Есть
простой, хотя и несовершенный, способ добиться согласованности
описаний в различных файлах. Это: включить во входные файлы,
содержащие операторы и определения данных, заголовочные файлы,
которые содержат интерфейсную информацию.
Средством включения текстов служит макрокоманда #include,
которая позволяет собрать в один файл (единицу трансляции)
несколько исходных файлов программы. Команда
#include "включаемый-файл"
заменяет строку, в которой она была задана, на содержимое файла
включаемый-файл. Естественно, это содержимое должно быть текстом
на С++, поскольку его будет читать транслятор. Как правило, операция
включения реализуется отдельной программой, называемой препроцессором
С++. Она вызывается системой программирования перед собственно
трансляцией для обработки таких команд во входном тексте. Возможно
и другое решение: часть транслятора, непосредственно работающая
с входным текстом, обрабатывает команды включения файлов по мере их
появления в тексте. В той системе программирования, в которой
работает автор, чтобы увидеть результат команд включения файлов,
нужно задать команду:
CC -E file.c
Эта команда для обработки файла file.c запускает препроцессор
(и только!), подобно тому, как команда CC без флага -E запускает сам
транслятор.
Для включения файлов из стандартных каталогов (обычно каталоги
с именем INCLUDE) надо вместо кавычек использовать угловые скобки
< и >. Например:
#include <stream.h> // включение из стандартного каталога
#include "myheader.h" // включение из текущего каталога
Включение из стандартных каталогов имеет то преимущество, что имена
этих каталогов никак не связаны с конкретной программой (обычно
вначале включаемые файлы ищутся в каталоге /usr/include/CC, а
затем в /usr/include). К сожалению, в этой команде пробелы существенны:
#include < stream.h> // <stream.h> не будет найден
Было бы нелепо, если бы каждый раз перед включением файла
требовалась его перетрансляция. Обычно включаемые файлы содержат
только описания, а не операторы и определения, требующие существенной
трансляторной обработки. Кроме того, система программирования
может предварительно оттранслировать заголовочные
файлы, если, конечно, она настолько развита, что способна сделать
это, не изменяя семантики программы.
Укажем, что может содержать заголовочный файл:
Определения типов struct point { int x, y; };
Шаблоны типов template<class T>
class V { /* ... */ }
Описания функций extern int strlen(const char*);
Определения inline char get() { return *p++; }
функций-подстановок
Описания данных extern int a;
Определения констант const float pi = 3.141593;
Перечисления enum bool { false, true };
Описания имен class Matrix;
Команды включения файлов #include <signal.h>
Макроопределения #define Case break;case
Комментарии /* проверка на конец файла */
Перечисление того, что стоит помещать в заголовочный файл, не является
требованием языка, это просто совет по разумному использованию включения
файлов. С другой стороны, в заголовочном файле никогда не должно быть:
Определений обычных функций char get() { return *p++; }
Определений данных int a;
Определений составных const tb[i] = { /* ... */ };
констант
По традиции заголовочные файлы имеют расширение .h, а файлы,
содержащие определения функций или данных, расширение .c. Иногда
их называют "h-файлы" или "с-файлы" соответственно. Используют
и другие расширения для этих файлов: .C, cxx, .cpp и
.cc. Принятое расширение вы найдете в своем справочном руководстве.
Макросредства описываются в $$4.7. Отметим только, что в С++ они
используются не столь широко, как в С, поскольку С++ имеет определенные
возможности в самом языке: определения констант (const),
функций-подстановок (inline), дающие возможность более простой
операции вызова, и шаблонов типа, позволяющие порождать семейство
типов и функций ($$8).
Совет помещать в заголовочный файл определения только простых,
но не составных, констант объясняется вполне прагматической причиной.
Просто большинство трансляторов не настолько разумно, чтобы
предотвратить создание ненужных копий составной константы. Вообще
говоря, более простой вариант всегда является более общим, а значит
транслятор должен учитывать его в первую очередь, чтобы создать
хорошую программу.
