Бьерн Страуструп (947334), страница 28

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

Текст из файла (страница 28)

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.

5.2.5 Удаление

Пользовательские типы чаще имеют, чем не имеют, конструкторы, которые

проводят надлежащую инициализацию. Для многих типов требуется и

обратная операция - деструктор, гарантирующая правильное удаление

объектов этого типа. Деструктор класса X обозначается ~X ("дополнение

конструктора"). В частности, для многих классов используется

свободная память (см. $$3.2.6), выделяемая конструктором и

освобождаемая деструктором. Вот, например, традиционное определение

типа стек, из которого для краткости полностью выброшена обработка

ошибок:

class char_stack {

int size;

char* top;

char* s;

public:

char_stack(int sz) { top=s=new char[size=sz]; }

~char_stack() { delete[] s; } // деструктор

void push(char c) { *top++ = c; }

void pop() { return *--top; }

};

Когда объект типа char_stack выходит из текущей области видимости,

вызывается деструктор:

void f()

{

char_stack s1(100);

char_stack s2(200);

s1.push('a');

s2.push(s1.pop());

char ch = s2.pop();

cout << ch << '\n';

}

Когда начинает выполняться f(), вызывается конструктор char_stack,

который размещает массив из 100 символов s1 и массив из 200

символов s2. При возврате из f() память, которая была занята обоими

массивами, будет освобождена.

5.2.6 Подстановка

Программирование с классами предполагает, что в программе появится

множество маленьких функций. По сути, всюду, где в программе с

традиционной организацией стояло бы обычное обращение к структуре

данных, используется функция. То, что было соглашением, стало

стандартом, проверяемым транслятором. В результате программа

может стать крайне неэффективной. Хотя вызов функции в C++

и не столь дорогостоящая операция по сравнению с другими

языками, все-таки цена ее много выше, чем у пары обращений к памяти,

составляющих тело тривиальной функции.

Преодолеть эту трудность помогают функции-подстановки (inline).

Если в описании класса функция-член определена, а не только описана,

то она считается подстановкой. Это значит, например, что при

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

не будет использоваться никаких операций вызова функций, кроме

реализации операций вывода! Другими словами, при разработке такого

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

Любое, даже самое маленькое действие, можно смело определять как

функцию без потери эффективности. Это замечание

снимает наиболее часто приводимый довод в пользу общих членов

данных.

Функцию-член можно описать со спецификацией inline и вне описания

класса:

class char_stack {

int size;

char* top;

char* s;

public:

char pop();

// ...

};

inline char char_stack::pop()

{

return *--top;

}

Отметим, что недопустимо описывать разные определения функции-члена,

являющейся подстановкой, в различных исходных файлах ($$R.7.1.2).

Это нарушило бы понятие о классе как о цельном типе.

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

Что представляет собой хороший класс? Это нечто, обладающее хорошо

определенным множеством операций. Нечто, рассматриваемое как

"черный ящик", управлять которым можно только посредством этих

операций. Нечто, чье фактическое представление можно изменить любым

мыслимым способом, но не изменяя при этом способа использования

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

Очевидные примеры хороших классов дают контейнеры разных видов:

таблицы, множества, списки, вектора, словари и т.д. Такой

класс имеет операцию занесения в контейнер. Обычно имеется и

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

Могут быть операции упорядочивания всех членов и просмотра их

в определенном порядке. Наконец, может быть операция удаления

члена. Обычно контейнерные классы имеют конструкторы и деструкторы.

5.3.1 Альтернативные реализации

Пока описание общей части класса и функций-членов остается неизменным,

можно, не влияя на пользователей класса, менять его реализацию.

В подтверждение этого рассмотрим таблицу имен из программы

калькулятора, приведенной в главе 3. Структура ее такова:

struct name {

char* string;

name* next;

double value;

};

А вот вариант класса table (таблица имен):

// файл table.h

class table {

name* tbl;

public:

table() { tbl = 0; }

name* look(char*, int = 0);

name* insert(char* s) { return look(s,1); }

};

Эта таблица отличается от определенной в главе 3 тем, что это

настоящий тип. Можно описать несколько таблиц, завести указатель

на таблицу и т.д. Например:

#include "table.h"

table globals;

table keywords;

table* locals;

main()

{

locals = new table;

// ...

}

Приведем реализацию функции table::look(), в которой используется

линейный поиск в списке имен таблицы:

#include <string.h>

name* table::look(char* p, int ins)

{

for (name* n = tbl; n; n=n->next)

if (strcmp(p,n->string) == 0) return n;

if (ins == 0) error("имя не найдено");

name* nn = new name;

nn->string = new char[strlen(p)+1];

strcpy(nn->string,p);

nn->value = 1;

nn->next = tbl;

tbl = nn;

return nn;

}

Теперь усовершенствуем класс table так, чтобы поиск имени шел

по ключу (хэш-функции от имени), как это и было сделано в примере

с калькулятором. Сделать это труднее, если соблюдать ограничение,

требующее, чтобы не все программы, использующие приведенную версию

класса table, надо было изменять:

class table {

name** tbl;

int size;

public:

table(int sz = 15);

~table();

name* look(char*, int = 0);

name* insert(char* s) { return look(s,1); }

};

Изменения в структуре данных и конструкторе произошли потому,

что для хэширования таблица должна иметь определенный размер.

Задание конструктора со стандартным значением параметра гарантирует,

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

останутся верными. Стандартные значения параметров полезны

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

пользователей класса. Теперь конструктор и деструктор создают и

уничтожают хэшированные таблицы:

table::table(int sz)

{

if (sz < 0) error("размер таблицы отрицателен");

tbl = new name*[size = sz];

for ( int i = 0; i<sz; i++) tbl[i] = 0;

}

table::~table()

{

for (int i = 0; i<size; i++) {

name* nx;

for (name* n = tbl[i]; n; n=nx) {

nx = n->next;

delete n->string;

delete n;

}

}

delete tbl;

}

Описав деструктор для класса name, можно получить более ясный и

простой вариант table::~table(). Функция поиска практически

совпадает с приведенной в примере калькулятора ($$3.13):

name* table::look(const char* p, int ins)

{

int ii = 0;

char* pp = p;

while (*pp) ii = ii<<1 ^ *pp++;

if (ii < 0) ii = -ii;

ii %= size;

for (name* n=tbl[ii]; n; n=n->next)

if (strcmp(p,n->string) == 0) return n;

name* nn = new name;

nn->string = new char[strlen(p)+1];

strcpy(nn->string,p);

nn->value = 1;

nn->next = tbl[ii];

tbl[ii] = nn;

return nn;

}

Очевидно, что функции-члены класса должны перетранслироваться всякий

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

такое изменение никак не должно отражаться на пользователях класса.

К сожалению, обычно бывает не так. Для размещения переменной, имеющей

тип класса, транслятор должен знать размер объекта класса. Если

размер объекта изменится, нужно перетранслировать файлы, в которых

использовался класс. Можно написать системную программу (и она даже

уже написана), которая будет определять минимальное множество файлов,

подлежащих перетрансляции после изменения класса. Но такая программа

еще не получила широкого распространения.

Возможен вопрос: почему С++ был спроектирован таким образом,

что после изменения частной части класса требуется перетрансляция

программ пользователя? Почему вообще частная часть класса

присутствует в описании класса? Иными словами, почему описания

частных членов присутствуют в заголовочных файлах, доступных

пользователю, если все равно недоступны для него в программе?

Ответ один - эффективность. Во многих системах программирования

процесс трансляции и последовательность команд, производящая

вызов функции, будет проще, если размер автоматических (т.е.

размещаемых в стеке) объектов известен на стадии трансляции.

Можно не знать определения всего класса, если представлять каждый

объект как указатель на "настоящий" объект. Это позволяет решить

задачу, поскольку все указатели будут иметь одинаковый размер, а

размещение настоящих объектов будет проводиться только в одном файле,

в котором доступны частные части классов. Однако, такое решение

приводит к дополнительному расходу памяти на каждый объект и

дополнительному обращению к памяти при каждом использовании члена.

Еще хуже, что каждый вызов функции с автоматическим объектом

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

К тому же становится невозможной реализация подстановкой

функций-членов, работающих с частными членами класса. Наконец,

такое изменение сделает невозможным связывание программ на С++ и на

С, поскольку транслятор С будет по другому обрабатывать структуры

(struct). Поэтому такое решение было сочтено неприемлемым для С++.

С другой стороны, С++ предоставляет средство для создания

абстрактных типов, в которых связь между интерфейсом пользователя

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

классы и описываются абстрактные базовые классы, а в $$13.3 поясняется,

как с помощью этих средств реализовать абстрактные типы. Цель этого -

дать возможность определять пользовательские типы столь же эффективные

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

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

эффективными.

5.3.2 Законченный пример класса

Программирование без упрятывания данных (в расчете на структуры)

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

программирование с упрятыванием данных (в расчете на классы).

Структуру можно определить не очень задумываясь о том, как ее

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

на том, чтобы обеспечить для нового типа полный набор операций.

Это важное смещение акцента в проектировании программ. Обычно

Характеристики

Список файлов книги