17.2.3. Резюме

Открытый интерфейс каждого из четырех производных классов состоит из их открытых членов и унаследованных открытых членов Query. Когда мы пишем:

Query *pq = new NmaeQuery( "Monet" );

то получить доступ к открытому интерфейсу Query можно только через pq. А если пишем:

pq->eval();

то вызывается реализация виртуальной eval() из производного класса, на объект которого указывает pq, в данном случае - из класса NameQuery. Строкой

pq->display();

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

void
Query::
display()
{
 if ( ! _solution->size() ) {
 cout < < " \n\tИзвините, " 
 < < " подходящих строк в тексте не найдено.\n" 
 < < endl;
 }

 set<short>::const_iterator
 it = _solution->begin(),
 end_it = _solution->end();

 for ( ; it != end_it; ++it ) {
 int line = *it;

 // не будем пользоваться нумерацией строк с 0...
 cout < < " (" < < line+1 < < " ) " 
 < < (*_text_file)[line] < < '\n';
 }

 cout < < endl;
}

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

Упражнение 17.3

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

class Library {
public:
 bool check_out( LibMember* ); // выдать
 bool check_in ( LibMember* ); // принять назад
 bool is_late( const Date& today ); // просрочил
 double apply_fine(); // наложить штраф
 ostream& print( ostream&=cout );

 Date* due_date() const; // ожидаемая дата возврата
 Date* date_borrowed() const; // дата выдачи

 string title() const; // название
 const LibMember* member() const; // записавшийся
};

Упражнение 17.4

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

Упражнение 17.5

Какие из следующих объявлений неправильны:

class base { ... };

(a) class Derived : public Derived { ... };
(b) class Derived : Base { ... };
(c) class Derived : private Base { ... };
(d) class Derived : public Base;
(e) class Derived inherits Base { ... };

17.3. Доступ к членам базового класса

Объект производного класса фактически построен из нескольких частей. Каждый базовый класс вносит свою долю в виде подобъекта, составленного из нестатических данных-членов этого класса. Объект производного класса построен из подобъектов, соответствующих каждому из его базовых, а также из части, включающей нестатические члены самого производного класса. Так, наш объект NameQuery состоит из подобъекта Query, содержащего члены _loc и _solution, и части, принадлежащей NameQuery, - она содержит только член _name.

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

void
NameQuery::
display_partial_solution( ostream &os )
{
 os < < _name
 < < " is found in "
 < < (_solution ? _solution->size() : 0)
 < < " lines of text\n";
}

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

NameQuery nq( "Frost" );

// вызывается NameQuery::eval()
nq.eval();

// вызывается Query::display()
nq.display();

либо непосредственно из тела другой (или той же самой) функции-члена:

void
NameQuery::
match_count()
{
 if ( ! _solution )
 // вызывается Query::_vec2set()
 _solution = _vec2set( &_loc );
 return _solution->size();
}

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

class Diffident {
public: // ...
protected:
 int _mumble;
 // ...
};

class Shy : public Diffident {
public: // ...
protected:
 // имя Diffident::_mumble скрыто
 string _mumble;

 // ...
};

В области видимости Shy употребление неквалифицированного имени _mumble разрешается в пользу члена _mumble класса Shy (объекта string), даже если такое использование в данном контексте недопустимо:

void
Shy::
turn_eyes_down()
{
 // ...
 _mumble = "excuse me"; // правильно

 // ошибка: int Diffident::_mumble скрыто
 _mumble = -1;
}

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

void
Shy::
turn_eyes_down()
{
 // ...
 _mumble = "excuse me"; // правильно

 // правильно: имя члена базового класса квалифицировано
 Diffident::_mumble = -1;
}

Функции-члены базового и производного классов не составляют множество перегруженных функций:

class Diffident {
public:
 void mumble( int softness );
 // ...
};

class Shy : public Diffident {
public:
 // скрывает видимость функции-члена Diffident::_mumble,
 // а не перегружает ее
 void mumble( string whatYaSay );
 void print( int soft, string words );
 // ...
};

Вызов функции-члена базового класса из производного в этом случае приводит к ошибке компиляции:

Shy simon;

// правильно: Shy::mumble( string )
simon.mumble( "pardon me" );

// ошибка: ожидался первый аргумент типа string
// Diffident::mumble( int ) невидима
simon.mumble( 2 );

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

class Diffident {
public:
 void turn_aside( );
 // ...
};

class Shy : public Diffident {
public:
 // скрывает видимость
 // Diffident::turn_aside()
 void turn_aside();

 // ...
};

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

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

class Shy : public Diffident {
public:
 // один из способов реализовать множество перегруженных
 // членов базового и производного классов
 void mumble( string whatYaSay );
 void mumble( int softness ) {
 Diffident::mumble( softness ); }
 // ...
};

Но в стандартном C++ тот же результат достигается посредством using-объявления:

class Shy : public Diffident {
public:
 // в стандартном C++ using-объявление
 // создает множество перегруженных
 // членов базового и производного классов
 void mumble( string whatYaSay );
 using Diffident::mumble;

 // ...
};

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

Обратим внимание на степень доступности защищенных членов базового класса. Когда мы пишем:

class Query {
public:
 const vector<location>* locations() { return &_loc; }
 // ...
protected:
 vector<location> _loc;
 // ...
};

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

bool
NameQuery::
compare( const Query *pquery )
{
 // правильно: защищенный член подобъекта Query
 int myMatches = _loc.size();

 // ошибка: нет прав доступа к защищенному члену
 // независимого объекта Query
 int itsMatches = pquery->_loc.size();

 return myMatches == itsMatches;
}

У объекта NameQuery есть доступ к защищенным членам только одного объекта Query - подобъекта самого себя. Прямое обращение к ним из производного класса осуществляется через неявный указатель this (см. раздел 13.4). Первая реакция на ошибку компиляции - переписать функцию compare() с использованием открытой функции-члена location():

bool
NameQuery::
compare( const Query *pquery )
{
 // правильно: защищенный член подобъекта Query
 int myMatches = _loc.size();

 // правильно: используется открытый метод доступа
 int itsMatches = pquery->locations()->size();

 return myMatches == itsMatches;
}

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

Этот вид ограничения доступа не распространяется на доступ изнутри класса к другим объектам того же класса:

bool
NameQuery::
compare( const NameQuery *pname )
{
 int myMatches = _loc.size(); // правильно
 int itsMatches = name->_loc.size(); // тоже правильно

 return myMatches == itsMatches;
}

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

Рассмотрим инициализацию указателя на базовый Query адресом объекта производного NameQuery:

Query *pb = new NameQuery( "sprite" );

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

pb->eval(); // вызывается NameQuery::eval()

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

если в Query и NameQuery объявлены некоторые невиртуальные функции-члены с одинаковым именем, то через pb всегда вызывается экземпляр из Query;

если в Query и NameQuery объявлены одноименные члены, то через pb обращение происходит к члену класса Query;

если в NameQuery имеется виртуальная функция, отсутствующая в Query, скажем suffix(), то попытка вызвать ее через pb приводит к ошибке компиляции:

// ошибка: suffix() - не член класса Query
pb->suffix();

Обращение к члену или невиртуальной функции-члену класса NameQuery через pb тоже вызывает ошибку компиляции:

// ошибка: _name - не член класса Query
pb->_name;

Квалификация имени члена в этом случае не помогает:

// ошибка: у класса Query нет базового класса NameQuery
pb->NameQuery::_name;

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

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

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

механизм виртуализации можно оптимизировать. Часто вызов такой функции оказывается не дороже, чем косвенный вызов функции по указателю (детально этот вопрос рассмотрен в [LIPPMAN96a]).

В базовом классе Query определен статический член _text_file:

static vector<string> *_text_file;

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

nameQueryObject._text_file; // правильно

Наконец, если производный класс хочет получить доступ к закрытым членам своего базового класса напрямую, то он должен быть объявлен другом базового: class Query { friend class NameQuery; public: // ... };

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

А если мы произведем от NameQuery класс StringQuery? Он будет поддерживать сокращенную форму запроса AndQuery, и вместо

beautiful && fiery && bird

можно будет написать:

"beautiful fiery bird"

Унаследует ли StringQuery от класса NameQuery дружественные отношения с Query? Нет. Отношение дружественности не наследуется. Производный класс не становится другом класса, который объявил своим другом один из базовых. Если производному классу требуется стать другом одного или более классов, то эти классы должны предоставить ему соответствующие права явно. Например, у класса StringQuery нет никаких специальных прав доступа по отношению к Query. Если расширенный доступ необходим, то Query должен разрешить его явно.

Упражнение 17.6

Даны следующие определения базового и производных классов:

class Base {
public:
 foo( int );
 // ...
protected:
 int _bar;
 double _foo_bar;
};

class Derived : public Base {
public:
 foo( string );
 bool bar( Base *pb );
 void foobar();
 // ...
protected:
 string _bar;
};

Исправьте ошибки в каждом из следующих фрагментов кода:

Derived d; d.foo( 1024 );
 (b) void Derived::foobar() { _bar = 1024; }
(c) bool Derived::bar( Base *pb )
 { return _foo_bar == pb->_foo_bar; }

17.4. Конструирование базового и производного классов

Напомним, что объект производного класса состоит из одного или более подобъектов, соответствующих базовым классам, и части, относящейся к самому производному. Например, NameQuery состоит из подобъекта Query и объекта-члена string. Для иллюстрации поведения конструктора производного класса введем еще один член встроенного типа:

class NameQuery : public Query {
public:
 // ...
protected:
 bool _present;
 string _name;
};

Если _present установлен в false, то слово _name в тексте отсутствует.

Рассмотрим случай, когда в NameQuery конструктор не определен. Тогда при определении объекта этого класса

NameQuery nq;

по очереди вызывается конструктор по умолчанию Query, а затем конструктор по умолчанию класса string (ассоциированный с объектом _name). Член _present остается неинициализированным, что потенциально может служить источником ошибок. Чтобы инициализировать его, можно так определить конструктор по умолчанию для класса NameQuery:

inline NameQuery::NameQuery() { _present = false; }

Теперь при определении nq вызываются три конструктора по умолчанию: для базового класса Query, для класса string при инициализации члена _name и для класса NameQuery.

А как передать аргумент конструктору базового класса Query? Ответить на этот вопрос можно, рассуждая по аналогии.

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

inline NameQuery::
NameQuery( const string &name )
 : _name( name ), _present( false )
{}

Для передачи одного или более аргументов конструктору базового класса также разрешается использовать список инициализации членов. В следующем примере мы передаем конструктору string аргумент name, а конструктору базового класса Query - объект, адресованный указателем ploc:

inline NameQuery::
NameQuery( const string &name,
 vector<location> *ploc )
 : _name( name ), Query( *ploc ), _present( true )
{}

Хотя Query помещен в список инициализации вторым, его конструктор всегда вызывается раньше конструктора для _name. Порядок их вызова следующий:

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

Конструктор объекта-члена. Если в классе есть несколько таких членов, то конструкторы вызываются в порядке их объявления в классе, а не в порядке появления в списке инициализации (подробнее см. раздел 14.5).

Конструктор производного класса.

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

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

17.4.1. Конструктор базового класса

В нашем базовом классе объявлено два нестатических члена: _solution и _loc:

class Query {
public:
 // ...
protected:
 set<short> *_solution;
 vector<location> _loc;
 // ...
};

Конструктор Query по умолчанию должен явно инициализировать только член _solution. Для инициализации _loc автоматически вызывается конструктор класса vector. Вот реализация нашего конструктора:

inline Query::Query(): _solution( 0 ) {}

В Query нам понадобится еще один конструктор, принимающий ссылку на вектор позиций:

inline
Query::
Query( const vector< locaton > &loc )
 : _solution( 0 ), _loc( loc )
{}

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

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

class Query {
public:
 // ...
protected:
 Query();
 // ...
};

Ко второму конструктору класса Query предъявляются еще более жесткие требования: он не только должен конструировать Query в виде подобъекта производного класса, но этот производный класс должен к тому же быть NameQuery. Можно объявить конструктор закрытым, а NameQuery сделать другом класса Query. (В предыдущем разделе мы говорили, что производный класс может получить доступ только к открытым и защищенным членам базового. Поэтому любая попытка вызвать второй конструктор из классов AndQuery, OrQuery или NotQuery приведет к ошибке компиляции.)

class Query {
public:
 // ...
protected:
 Query();
 // ...
private:
 explicit Query( const vector<location>& );
};

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

17.4.2. Конструктор производного класса

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

class NameQuery : public Query {
public:
 explicit NameQuery( const string& );
 NameQuery( const string&, const vector* );
 // ...
protected:
 // ...
};

Конструктор с одним параметром принимает в качестве аргумента строку. Она передается конструктору объекта типа string, который вызывается для инициализации члена _name. Конструктор по умолчанию базового класса Query вызывается неявно:

inline
NameQuery::
NameQuery( const string &name )
 // Query::Query() вызывается неявно
 : _name( name )
{}

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

inline
NameQuery::
NameQuery( const string &name, vector< location> *ploc )
 : _name( name ), Query( *ploc )
{}

Конструкторы можно использовать так:

string title( "Alice " );
NameQuery *pname;

// проверим, встречается ли "Alice " в отображении слов
// если да, получить ассоциированный с ним вектор позиций

if ( vector< location > *ploc = retrieve_location( title ))
 pname = new NameQuery( title, ploc );
else pname = new NameQuery( title );

В каждом из классов NotQuery, OrQuery и AndQuery определено по одному конструктору, каждый из которых вызывает конструктор базового класса неявно:

inline NotQuery::
NotQuery( Query *op = 0 ) : _op( op ) {}

inline OrQuery::
OrQuery( Query *lop = 0, Query *rop = 0 )
 : _lop( lop ), _rop( rop )
{}

inline AndQuery::
AndQuery( Query *lop = 0, Query *rop = 0 )
 : _lop( lop ), _rop( rop )
{}

(В разделе 17.7 мы построим объекты каждого из производных классов для представления различных запросов пользователя.)

17.4.3. Альтернативная иерархия классов

Хотя наша иерархия классов Query представляется вполне приемлемой, она вовсе не является единственно возможной. Например, AndQuery и OrQuery связаны с бинарной операцией, поэтому они в какой-то степени дублируют друг друга. Можно вынести все данные и функции-члены, общие для них, в абстрактный базовый класс BinaryQuery. Поддерево новой иерархии Query изображено на рисунке 17.2:

Query
BinaryQuery
AndQuery OrQuery

Рис. 17.2. Альтернативная иерархия классов

Класс BinaryQuery - это тоже абстрактный базовый класс, следовательно, его фактические объекты в приложении не появляются. Разумной реализации eval() для него предложить нельзя, поэтому чисто виртуальная функция, объявленная в Query, в классе BinaryQuery останется чисто виртуальной. (Подробнее о таких функциях мы поговорим в разделе 17.5.)

Две функции-члена для доступа - lop() и rop(), общие для обоих классов, переносятся выше, в BinaryQuery, и определяются как нестатические встроенные. Аналогично два члена _lop и _rop, объявленные в обоих классах, также переносятся в BinaryQuery и становятся нестатическими и защищенными. Открытые конструкторы обоих производных классов объединяются в один защищенный конструктор BinaryQuery:

class BinaryQuery : public Query {
public:
 const Query *lop() { return _lop; }
 const Query *rop() { return _rop; }

protected:
 BinaryQuery( Query *lop, Query *rop )
 : _lop( lop ), _rop( rop )
 {}

 Query *_lop;
 Query *_rop;
};

Складывается впечатление, что теперь оба производных класса должны предоставить лишь подходящие реализации eval():

// увы! эти определения классов некорректны

class OrQuery : public BinaryQuery {
public:
 virtual void eval();
};

class AndQuery : public BinaryQuery {
public:
 virtual void eval();
};

Однако в том виде, в котором мы их определили, эти классы неполны. При компиляции самих определений ошибок не возникает, но если мы попытаемся определить фактический объект:

// ошибка: отсутствует конструктор класса AndQuery
AndQuery proust( new NameQuery( "marcel" ),
 new NameQuery( "proust " ));

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

Мы предположили, что AndQuery и OrQuery наследуют конструктор BinaryQuery точно так же, как они наследуют функции-члены lop() и rop(). Однако производный класс не наследует конструкторов базового. (Это могло бы привести к ошибкам, связанным с неинициализированными членами производного класса. Представьте, что будет, если в AndQuery добавить пару членов, не являющихся объектами классов: унаследованный конструктор базового класса для инициализации объекта производного AndQuery применять уже нельзя. Однако программист может этого не осознавать. Ошибка проявится не при конструировании объекта AndQuery, а позже, при его использовании. Кстати говоря, перегруженные операторы new и delete наследуются, что иногда приводит к аналогичным проблемам.)

Каждый производный класс должен предоставлять собственный набор конструкторов. В случае классов AndQuery и OrQuery единственная цель конструкторов - обеспечить интерфейс для передачи двух своих операндов конструктору BinaryQuery. Так выглядит исправленная реализация:

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

class OrQuery : public BinaryQuery {
public:
 OrQuery( Query *lop, Query *rop )
 : BinaryQuery( lop, rop ) {}

 virtual void eval();
};

class AndQuery : public BinaryQuery {
public:
 AndQuery( Query *lop, Query *rop )
 : BinaryQuery( lop, rop ) {}

 virtual void eval();
};

Если мы еще раз взглянем на рис. 17.2, то увидим, что BinaryQuery - непосредственный базовый класс для AndQuery и OrQuery, а Query -для BinaryQuery. Таким образом, Query не является непосредственным базовым классом для AndQuery и OrQuery.

Конструктору производного класса разрешается напрямую вызывать только конструктор своего непосредственного предшественника в иерархии (виртуальное наследование является исключением из этого правила, да и из многих других тоже: см. раздел 18.5). Например, попытка включить конструктор Query в список инициализации членов объекта AndQuery приведет к ошибке.

При определении объектов классов AndQuery и OrQuery теперь вызываются три конструктора: для базового Query, для непосредственного базового класса BinaryQuery и для производного AndQuery или OrQuery. (Порядок вызова конструкторов базовых классов отражает обход дерева иерархии наследования в глубину.) Дополнительный уровень иерархии, связанный с BinaryQuery, практически не влияет на производительность, поскольку мы определили его конструкторы как встроенные.

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

17.4.4. Отложенное обнаружение ошибок

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

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

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

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

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

17.4.5. Деструкторы

Когда заканчивается время жизни объекта производного класса, автоматически вызываются деструкторы производного и базового классов (если они определены), а также деструкторы всех объектов-членов. Например, если имеется объект класса NameQuery:

NameQuery nq( "hyperion" );

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

Вот деструкторы нашего базового Query и производных от него (все они объявлены открытыми членами соответствующих классов):

inline Query::
~Query(){ delete _solution; }

inline NotQuery::
~NotQuery(){ delete _op; }

inline OrQuery::
~OrQuery(){ delete _lop; delete _rop; }

inline AndQuery::
~AndQuery(){ delete _lop; delete _rop; }

Отметим два аспекта:

мы не предоставляем явного деструктора NameQuery, потому что никаких специальных действий по очистке его объекта предпринимать не нужно. Деструкторы базового класса и класса string для члена _name вызываются автоматически;

в деструкторах производных классов оператор delete применяется к указателю типа Query*. Чтобы вызвать не деструктор Query, а деструктор класса того объекта, который фактически адресуется этим указателем, мы должны объявить деструктор базового Query виртуальным. (Более подробно о виртуальных функциях вообще и о виртуальных деструкторах в частности мы поговорим в следующем разделе.)

В нашей реализации неявно подразумевалось, что память для операндов, указатели на которые имеются в объектах классов NotQuery, OrQuery и AndQuery, выделена из хипа. Именно поэтому в деструкторах мы применяли к этим указателям оператор delete. Но язык не позволяет обеспечить истинность такого предположения, так как в нем нет различий между адресами в хипе и вне его. С этой точки зрения наша реализация не застрахована от ошибок.

В разделе 17.7 мы инкапсулируем выделение памяти и конструирование объектов иерархии Query в управляющий класс UserQuery. Это гарантирует выполнение нашего предположения. На уровне программы в целом следует перегрузить операторы new и delete для классов иерархии. Например, можно поступить следующим образом. Оператор new устанавливает в объекте флажок, говорящий, что память для него выделена из хипа. Перегруженный оператор delete проверяет этот флажок: если он есть, то память освобождается с помощью стандартного оператора delete.

Упражнение 17.7

Идентифицируйте конструкторы и деструкторы базового и производных классов для той иерархии, которую вы выбрали в упражнении 17.2 (раздел 17.1).

Упражнение 17.8

Измените реализацию класса OrQuery так, чтобы он был производным от BinaryQuery.

Упражнение 17.9

Найдите ошибку в следующем определении класса:

class Object {
public:
 virtual ~Object();
 virtual string isA();
protected:
 string _isA;
private:
 Object( string s ) : _isA( s ) {}
};

Упражнение 17.10

Дано определение базового класса:

class ConcreteBase {
public:
 explicit ConcreteBase( int );
 virtual ostream& print( ostream& );
 virtual ~Base();

 static int object_count();
protected:
 int _id;
 static int _object_count;
};

Что неправильно в следующих фрагментах:

(a) class C1 : public ConcreteBase {
 public:
 C1( int val )
 : _id( _object_count++ ) {}
 // ...
 };
(b) class C2 : public C1 {
 public:
 C2( int val )
 : ConcreteBase( val ), C1( val ) {}
 // ...
 };
(c) class C3 : public C2 {
 public:
 C3( int val )
 : C2( val ), _object_count( val ) {}
 // ...
 };
(d) class C4 : public ConcreteBase {
 public:
 C4( int val )
 : ConcreteBase ( _id+val ){}
 // ...
 };

Упражнение 17.11

В первоначальном определении языка C++ порядок следования инициализаторов в списке инициализации членов определял порядок вызова конструкторов. Принцип, который действует сейчас, был принят в 1986 году. Как вы думаете, почему была изменена исходная спецификация?

17.5. Виртуальные функции в базовом и производном классах

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

void Query::display( Query *pb )
{
 set> short> *ps = pb->solutions();
 // ...
 display();
}

Статический тип pb - это Query*. При обращении к невиртуальному члену solutions() вызывается функция-член класса Query. Невиртуальная функция display() вызывается через неявный указатель this. Статическим типом указателя this также является Query*, поэтому вызвана будет функция-член класса Query.

Чтобы объявить функцию виртуальной, нужно добавить ключевое слово virtual:

class Query {
public:
 virtual ostream& print( ostream* = cout ) const;
 // ...
};

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

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

NameQuery nq( "lilacs" );
// правильно: но nq "усечено" до подобъекта Query
Query qobject = nq;

Инициализация qobject переменной nq абсолютно законна: теперь qobject равняется подобъекту nq, который соответствует базовому классу Query, однако qobject не является объектом NameQuery. Часть nq, принадлежащая NameQuery, "усечена” перед инициализацией qobject, поскольку она не помещается в область памяти, отведенную под объект Query. Для поддержки этой парадигмы приходится использовать указатели и ссылки, но не сами объекты:

void print ( Query object,
 const Query *pointer,
 const Query &reference )
{
 // до момента выполнения невозможно определить,
 // какой экземпляр print() вызывается
 pointer->print();
 reference.print();

 // всегда вызывается Query::print()
 object.print();
}

int main()
{
 NameQuery firebird( " firebird" );
 print( firebird, &firebird, firebird );
}

В данном примере оба обращения через указатель pointer и ссылку reference разрешаются своим динамическим типом; в обоих случаях вызывается NameQuery::print(). Обращение же через объект object всегда приводит к вызову Query::print(). (Пример программы, в которой используется эффект "усечения", приведен в разделе 18.6.2.)

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

17.5.1. Виртуальный ввод/вывод

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

ostream& print( ostream &os = cout ) const;

Функцию print() следует объявить виртуальной, поскольку ее реализации зависят от типа, но нам нужно вызывать ее через указатель типа Query*. Например, для класса AndQuery эта функция могла бы выглядеть так:

ostream&
AndQuery::print( ostream &os ) const
{
 _lop->print( os );
 os < " && " ;
 _rop->print( os );
}

Необходимо объявить print() виртуальной функцией в абстрактном базовом Query, иначе мы не сможем вызвать ее для членов классов AndQury, OrQuery и NotQuery, являющихся указателями на операнды соответствующих запросов типа Query*. Однако для самого Query разумной реализации print() не существует. Поэтому мы определим ее как пустую функцию, а потом сделаем чисто виртуальной:

class Query {
public:
 virtual ostream& print( ostream &os=cout ) const {}
 // ...
};

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

// ошибка: ключевое слово virtual может появляться
// только в определении класса
virtual ostream& Query::print( ostream& ) const { ... }

Правильный вариант не должен включать слово virtual.

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

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

fiery && bird || shyly

пользователь ищет вхождения пары слов

fiery bird

или одного слова

shyly

С другой стороны, запрос

fiery && ( bird || hair )

найдет все вхождения любой из пар

fiery bird

или

fiery hair

Если наши реализации print() не будут показывать скобки в исходном запросе, то для пользователя они окажутся почти бесполезными. Чтобы сохранить эту информацию, введем в наш абстрактный базовый класс Query два нестатических члена, а также функции доступа к ним (подобное расширение класса - естественная часть эволюции иерархии):

class Query {
public:
 // ...

 // установить _lparen и _rparen
 void lparen( short lp ) { _lparen = lp; }
 void rparen( short rp ) { _rparen = rp; }

 // получить значения_lparen и _rparen
 short lparen() { return _lparen; }
 short rparen() { return _rparen; }

 // напечатать левую и правую скобки
 void print_lparen( short cnt, ostream& os ) const;
 void print_rparen( short cnt, ostream& os ) const;

protected:

 // счетчики левых и правых скобок
 short _lparen;
 short _rparen;
 // ...
};

_lparen - это количество левых, а _rparen - правых скобок, которое должно быть выведено при распечатке объекта. (В разделе 17.7 мы покажем, как вычисляются такие величины и как происходит присваивание обоим членам.) Вот пример обработки запроса с большим числом скобок:

==> ( untamed || ( fiery || ( shyly ) ) )
evaluate word: untamed
_lparen: 1
_rparen: 0
evaluate Or
_lparen: 0
_rparen: 0

evaluate word: fiery
_lparen: 1
_rparen: 0

evaluate 0r
_lparen: 0
_rparen: 0

evaluate word: shyly
_lparen: 1
_rparen: 0

evaluate right parens:
_rparen: 3

( untamed ( 1 ) lines match
( fiery ( 1 ) lines match
( shyly ( 1 ) lines match
( fiery || (shyly ( 2 ) lines match3
( untamed || ( fiery || ( shyly ))) ( 3 ) lines match

Requested query: ( untamed || ( fiery || ( shyly ) ) )
( 3 ) like a fiery bird in flight. A beautiful fiery bird, he tells her,
( 4 ) magical but untamed. "Daddy, shush, there is no such thing,"
( 6 ) Shyly, she asks, "I mean, Daddy, is there?"

Реализация print() для класса NameQuery:

ostream&
NameQuery::
print( ostream &os ) const
{
 if ( _lparen )
 print_lparen( _lparen, os );

 os << _name;

 if ( _rparen )
 print_rparen( _rparen, os );

 return os;
}

А так выглядит объявление:

class NameQuery : public Query {
public:
 virtual ostream& print( ostream &os ) const;
 // ...
};

Чтобы реализация виртуальной функции в производном классе замещала реализацию из базового, прототипы функций обязаны совпадать. Например, если бы мы опустили слово const или объявили еще один параметр, то реализация print() в NameQuery не заместила бы реализацию из базового класса. Возвращаемые значения также должны быть одинаковыми за одним исключением: значение, возвращенное реализацией в производном классе, может принадлежать к типу класса, который открыто наследует классу значения, возвращаемого реализацией в базовом классе. Если бы реализация из базового класса возвращала значение типа Query*, то реализация из производного могла бы возвращать NameQuery*. (Позже при работе с функцией clone() мы покажем, зачем это нужно.) Вот объявление и реализация print() в NotQuery:

class NotQuery : public Query {
public:
 virtual ostream& print( ostream &os ) const;
 // ...
};
ostream&
NotQuery::
print( ostream &os ) const
{
 os << " ! ";

 if ( _lparen )
 print_lparen( _lparen, os );

 _op->print( os );

 if ( _rparen )
 print_rparen( _rparen, os );

 return os;
}

Разумеется, вызов print() через _op - виртуальный.

Объявления и реализации этой функции в классах AndQuery и OrQuery практически дублируют друг друга. Поэтому приведем их только для AndQuery:

class AndQuery : public Query {
public:
 virtual ostream& print( ostream &os ) const;
 // ...
};
ostream&
AndQuery::
print( ostream &os ) const
{
 if ( _lparen )
 print_lparen( _lparen, os );

 _lop->print( os );
 os << " && ";
 _rop->print( os );

 if ( _rparen )
 print_rparen( _rparen, os );

 return os;
}

Такая реализация виртуальной функции print() позволяет вывести любой подтип Query в поток класса ostream или любого другого, производного от него:

cout << " Был сформулирован запрос " ;
Query *pq = retrieveQuery();
pq->print( cout );

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

Query *pq = retrieveQuery();
cout << " В ответ на запрос " 
 << *pq
 << " получены следующие результаты:\n" ;

Мы не можем непосредственно предоставить виртуальный оператор вывода, поскольку они являются членами класса ostream. Вместо этого мы должны написать косвенную виртуальную функцию:

inline ostream&
operator<< ( ostream &os, const Query &q )
{
 // виртуальный вызов print()
 return q.print( os );
}

Строки

AndQuery query;
// сформулировать запрос ...
cout << query << endl;

вызывают наш оператор вывода в ostream, который в свою очередь вызывает

q.print( os )

где q привязано к объекту query класса AndQuery, а os - к cout. Если бы вместо этого мы написали:

NameQuery query2( " Salinger" );
cout << query2 << endl;

то была бы вызвана реализация print() из класса NameQuery. Обращение

Query *pquery = retrieveQuery();
cout << *pquery << endl;

приводит к вызову той функции print(), которая ассоциирована с объектом, адресуемым указателем pquery в данной точке выполнения программы.

17.5.2. Чисто виртуальные функции

С точки зрения кодирования основная задача, стоящая перед нами в связи с поддержкой пользовательских запросов, - это реализация зависимых от типа операций для каждого из возможных операторов. Для этого мы определили четыре конкретных типа классов: AndQuery, OrQuery и т.д. Однако с точки зрения проектирования наша цель - инкапсулировать обработку каждого вида запроса, спрятать за не зависящим от типа интерфейсом. Это позволит построить ядро приложения, которое не потребует изменений при добавлении или удалении типов.

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

void doit_and_bedone( vector< Query* > *pvec )
{
 vector<Query*>::iterator
 it = pvec->begin(),
 end_it = pvec->end();

 for ( ; it != end_it; ++it )
 {
 Query *pq = *it;
 cout << "обрабатывается " << *pq << endl;
 pq->eval();
 pq->display();
 delete pq;
 }
}

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

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

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

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

class Query {
public:
 // объявляется чисто виртуальная функция
 virtual ostream& print( ostream&=cout ) const = 0;
 // ...
};

Заметьте, что за объявлением функции следует присваивание нуля.

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

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

// правильно: подобъект Query в составе NameQuery
Query *pq = new NameQuery( " Nostromo" );

// ошибка: оператор new создает объект класса Query
Query *pq2 = new Query;

Абстрактный базовый класс может существовать только как подобъект в составе объекта некоторого производного от него класса. Это именно та семантика, которая нужна нам для базового Query.