<< Пред.           стр. 86 (из 121)           След. >>

Список литературы по разделу

 NameQuery *pnq2 = pnq->clone(); // правильно
 Так выглядит реализация clone() в классе NotQuery:
 class NotQuery : public Query {
 public:
  virtual NotQuery *clone()
  { return new NotQuery( *this ); }
 
  // ...
 };
 Реализации в AndQuery и OrQuery аналогичны. Чтобы эти реализации clone() работали правильно, в классах NotQuery, AndQuery и OrQuery должны быть явно определены копирующие конструкторы. (Мы займемся этим в разделе 17.6.)
 17.5.8. Виртуальные функции, конструкторы и деструкторы
 Как мы видели в разделе 17.4, для объекта производного класса сначала вызывается конструктор базового, а затем производного класса. Например, при таком определении объекта NameQuery
 NameQuery poet( "Orlen" );
 сначала будет вызван конструктор Query, а потом NameQuery.
 При выполнении конструктора базового класса Query часть объекта, соответствующая классу NameQuery, остается неинициализированной. По существу, poet – это еще не объект NameQuery, сконструирован лишь его подобъект.
 Что должно происходить, если внутри конструктора базового класса вызывается виртуальная функция, реализации которой существуют как в базовом, так и в производном классах? Какая из них должна быть вызвана? Результат вызова реализации из производного класса в случае, когда необходим доступ к его членам, оказался бы неопределенным. Вероятно, выполнение программы закончилось бы крахом.
 Чтобы этого не случилось, в конструкторе базового класса всегда вызывается реализация виртуальной функции, определенная именно в базовом. Иными словами, внутри такого конструктора объект производного класса рассматривается как имеющий тип базового.
 То же самое справедливо и внутри деструктора базового класса, вызываемого для объекта производного. И в этом случае часть объекта, относящаяся к производному классу, не определена: не потому, что еще не сконструирована, а потому, что уже уничтожена.
 Упражнение 17.12
 Внутри объекта NameQuery естественное внутреннее представление вектора позиций – это указатель, который инициализируется указателем, хранящимся в отображении слов. Оно же является и наиболее эффективным, так как нам нужно скопировать лишь один адрес, а не каждую пару координат. Классы AndQuery, OrQuery и NotQuery должны конструировать собственные векторы позиций на основе вычисления своих операндов. Когда время жизни объекта любого из этих классов завершается, ассоциированный с ним вектор позиций необходимо удалить. Когда же заканчивается время жизни объекта NameQuery, вектор позиций удалять не следует. Как сделать так, чтобы вектор позиций был представлен указателем в базовом классе Query и при этом его экземпляры для объектов AndQuery, OrQuery и NotQuery удалялись, а для объектов NameQuery – нет? (Заметим, что нам не разрешается добавить в класс Query признак, показывающий, нужно ли применять оператор delete к вектору позиций!)
 Упражнение 17.13
 Что неправильно в приведенном определении класса:
 class AbstractObject {
 public:
  ~AbstractObject();
  virtual void doit() = 0;
  // ...
 };
 Упражнение 17.14
 Даны такие определения:
 NameQuery nq( "Sneezy" );
 Query q( nq );
 Query *pq = &nq;
 Почему в инструкции
 pq->eval();
 вызывается экземпляр eval() из класса NameQuery, а в инструкции
 q.eval();
 экземпляр из Query?
 Упражнение 17.15
 Какие из повторных объявлений виртуальных функций в классе Derived неправильны:
 (a) Base* Base::copy( Base* );
  Base* Derived::copy( Derived* );
 (b) Base* Base::copy( Base* );
  Derived* Derived::copy( Vase* );
 (c) ostream& Base::print( int, ostream&=cout );
  ostream& Derived::print( int, ostream& );
 (d) void Base::eval() const;
  void Derived::eval();
 Упражнение 17.16
 Маловероятно, что наша программа заработает при первом же запуске и в первый раз, когда прогоняется с реальными данными. Средства отладки полезно включать уже на этапе проектирования классов. Реализуйте в нашей иерархии классов Query виртуальную функцию debug(), которая будет отображать члены соответствующих классов. Поддержите управление уровнем детализации двумя способами: с помощью аргумента, передаваемого функции debug(), и с помощью члена класса. (Последнее позволяет включать или отключать выдачу отладочной информации в отдельных объектах.)
 Упражнение 17.17
 Найдите ошибку в следующей иерархии классов:
 class Object {
 public:
  virtual void doit() = 0;
  // ...
 protected:
  virtual ~Object();
 };
 
 class MyObject : public Object {
 public:
  MyObject( string isA );
  string isA() const;
 protected:
  string _isA;
 };
 17.6. Почленная инициализация и присваивание A
 При проектировании класса мы должны позаботиться о том, чтобы почленная инициализация (см. раздел 14.6) и почленное присваивание (см. раздел 14.7) были реализованы правильно и эффективно. Рассмотрим связь этих операций с наследованием.
 До сих пор мы не занимались явной обработкой почленной инициализации. Посмотрим, что происходит в нашей иерархии классов Query по умолчанию.
 В абстрактном базовом классе Query определены три нестатических члена:
 class Query {
 public: // ...
 protected:
  int _paren;
  set *_solition;
  vector _loc;
  // ...
 };
 Член _solution, если он установлен, адресует множество, память для которого выделена в хипе функцией-членом _vec2set(). Деструктор Query применяет к _solution оператор delete.
 Класс Query должен предоставлять как явный копирующий конструктор, так и явный копирующий оператор присваивания. (Если вам это непонятно, перечитайте раздел 14.6.) Но сначала посмотрим, как почленное копирование по умолчанию происходит без них.
 Производный класс NameQuery содержит объект-член типа string и подобъект базового Query. Если есть объект folk класса NameQuery:
 NameQuery folk( "folk" );
 то инициализация music с помощью folk
 NameQuery music = folk;
 осуществляется так:
 Компилятор проверяет, есть ли в NameQuery явный копирующий конструктор. (Его нет. Поэтому необходимо применить почленную инициализацию по умолчанию.)
 Далее компилятор проверяет, содержит ли объект NameQuery подобъекты базового класса. (Да, в нем имеется подобъект Query.)
 Компилятор проверяет, определен ли в классе Query явный копирующий конструктор. (Нет, поэтому компилятор применит почленную инициализацию по умолчанию.)
 Компилятор проверяет, содержит ли объект Query подобъекты базового класса. (Нет.)
 Компилятор просматривает все нестатические члены Query в порядке их объявления. (Если некоторый член не является объектом класса, как, например, _paren и _solution, то в объекте music он инициализируется соответствующим членом объекта folk. Если же является, как, скажем, _loc, то к нему рекурсивно применяется шаг 1. В классе vector определен копирующий конструктор, который вызывается для инициализации music._loc с помощью folk._loc.)
 Далее компилятор рассматривает нестатические члены NameQuery в порядке их объявления и находит объект класса string, где есть явный копирующий конструктор. Он и вызывается для инициализации music._name с помощью folk._name.
 Инициализация по умолчанию music с помощью folk завершена. Она хороша во всех отношениях, кроме одного: если разрешить копирование по умолчанию члена _solution, то программа, скорее всего, завершится аварийно. Поэтому вместо такой обработки мы предоставим явный копирующий конструктор класса Query. Можно, например, скопировать все разрешающее множество:
 Query::Query( const Query &rhs )
  : _loc( rhs._loc ), _paren(rhs._paren)
 {
  if ( rhs._solution )
  {
  _solution = new set;
  set::iterator
  it = rhs._solution->begin(),
  end_it = rhs._solution->end();
 
  for ( ; _ir != end_it; ++it )
  _solution->insert( *it );
  }
  else _solution = 0;
 }
 Однако, поскольку в нашей реализации разрешающее множество вычисляется по мере необходимости, копировать его сразу нет нужды. Назначение нашего копирующего конструктора – предотвратить копирование по умолчанию. Для этого достаточно инициализировать _solution нулем:
 Query::Query( const Query &rhs )
  : _loc( rhs._loc ),
  _paren(rhs._paren), _solution( 0 )
 {}
 Шаги 1 и 2 инициализации musiс c помощью folk те же, что и раньше. Но на шаге 3 компилятор обнаруживает, что в классе Query есть явный копирующий конструктор и вызывает его. Шаги 4 и 5 пропускаются, а шаг 6 выполняется, как и прежде.
 На этот раз почленная инициализация music с помощью folk корректна. Реализовывать явный копирующий конструктор в NameQuery нет необходимости.
 Объект производного класса NotQuery содержит подобъект базового Query и член _op типа Query*, который указывает на операнд, размещенный в хипе. Деструктор NotQuery применяет к этому операнду оператор delete.
 Для класса NotQuery почленная инициализация по умолчанию члена _op небезопасна, поэтому необходим явный копирующий конструктор. В его реализации используется виртуальная функция clone(), которую мы определили в предыдущем разделе.
 inline NotQuery::
 NotQuery( const NotQuery &rhs )
  // вызывается Query::Query( const Query &rhs )
  : Query( rhs )
  { _op = rhs._op->clone(); }
 При почленной инициализации одного объекта класса NotQuery другим выполняются два шага:
 Компилятор проверяет, определен ли в NotQuery явный копирующий конструктор. Да, определен.
 Этот конструктор вызывается для почленной инициализации.
 Вот и все. Ответственность за правильную инициализацию подобъекта базового класса и нестатических членов возлагается на копирующий конструктор NotQuery. (Классы AndQuery и OrQuery сходны с NotQuery, поэтому мы оставляем их в качестве упражнения для читателей.)
 Почленное присваивание аналогично почленной инициализации. Если имеется явный копирующий оператор присваивания, то он вызывается для выполнения присваивания одного объекта класса другому. В противном случае применяется почленное присваивание по умолчанию.
 Если базовый класс есть, то сначала с помощью копирующего оператора присваивания почленно присваивается подобъект данного класса, иначе такое присваивание рекурсивно применяется к базовым классам и членам подобъекта базового класса.
 Просматриваются все нестатические члены в порядке их объявления. Если член не является объектом класса, то его значение справа от знака равенства копируется в значение соответствующего члена слева от знака равенства. Если же член является объектом класса, в котором определен явный копирующий оператор присваивания, то он и вызывается. В противном случае к базовым классам и членам объекта-члена применяется почленное присваивание по умолчанию.
 Вот как выглядит копирующий оператор присваивания для нашего объекта Query. Еще раз отметим, что в этом месте необязательно копировать разрешающее множество, достаточно предотвратить копирование по умолчанию:
 Query&
 Query::
 operator=( const Query &rhs )
 {
  // предотвратить присваивание самому себе
  if ( &rhs != this )
  {
  _paren = rhs._paren;
  _loc = rhs._loc;
  delete _solution;
  _solution = 0;
  }
 
  return *this;
 };
 В классе NameQuery явный копирующий оператор присваивания не нужен. Присваивание одного объекта NameQuery другому выполняется в два шага:
 Для присваивания подобъектов Query двух объектов NameQuery вызывается явный копирующий оператор присваивания класса Query.
 Для присваивания членов string вызывается явный копирующий оператор присваивания этого класса.
 Для объектов NameQuery вполне достаточно почленного присваивания по умолчанию.
 В каждом из классов NotQuery, AndQuery и OrQuery для безопасного копирования операндов требуется явный копирующий оператор присваивания. Вот его реализация для NotQuery:
 inline NotQuery&
 NotQuery::
 operator=( const NotQuery &rhs )
 {
  // предотвратить присваивание самому себе
  if ( &rhs != this )
  {
  // вызвать копирующий оператор присваивания Query
  this->Query::operator=( rhs );
 
  // скопировать операнд
  _op = rhs._op->clone();
  }
 
  return *this;
 }
 В отличие от копирующего конструктора, в копирующем операторе присваивания нет специальной части, через которую вызывается аналогичный оператор базового класса. Для этого используются две синтаксических конструкции: явный вызов, продемонстрированный выше, и явное приведение типа, как в следующем примере:
 (*static_cast(this)) = rhs;
 (Реализация копирующих операторов присваивания в классах AndQuery и OrQuery выглядит так же, поэтому мы оставим ее в качестве упражнения.)
 Ниже предложена небольшая программа для тестирования данной реализации. Мы создаем или копируем объект, а затем распечатываем его.
 #include "Query.h"
 
 int
 main()
 {
  NameQuery nm( "alice" );
  NameQuery nm( "emma" );
 
  NotQuery nq1( &nm );
  cout << "notQuery 1: " << nq1 << endl;
 
  NotQuery nq2( nq1 );
  cout << "notQuery 2: " << nq2 << endl;
  NotQuery nq3( &nm2 );
  cout << "notQuery 3: " << nq3 << endl;
 
  nq3 = nq2;
  cout << "notQuery 3 присвоено значение nq2: " << nq3 << endl;
 
  AndQuery aq( &nq1, &nm2 );
  cout << "AndQuery : " << aq << endl;
 
  AndQuery aq2( aq );
  cout << "AndQuery 2: " << aq2 << endl;
 
  AndQuery aq3( &nm, &nm2 );
  cout << "AndQuery 3: " << aq3 << endl;
 
  aq2 = aq3;
  cout << "AndQuery 2 после присваивания: " << aq2 << endl;
 }
 После компиляции и запуска программа печатает следующее:
 
 notQuery 1: ! alice
 notQuery 2: ! alice
 notQuery 3: ! emma
 notQuery 3 присвоено значение nq2: ! alice
 AndQuery : ! alice && emma
 AndQuery 2: ! alice && emma
 AndQuery 3: alice && emma
 AndQuery 2 после присваивания: alice && emma
 
 Упражнение 17.18
 Реализуйте копирующие конструкторы в классах AndQuery и OrQuery.
 Упражнение 17.19
 Реализуйте копирующие операторы присваивания в классах AndQuery и OrQuery.
 Упражнение 17.20
 Что указывает на необходимость реализации явных копирующего конструктора и копирующего оператора присваивания?
 17.7. Управляющий класс UserQuery
 Если имеется запрос такого типа:
 
 fiery && ( bird || potato )
 
 то в нашу задачу входит построение эквивалентной иерархии классов:
 AndQuery
  NameQuery( "fiery" )
  OrQuery
  NameQuery( "bird" )
  NameQuery( "potato" )
 Как лучше всего это сделать? Процедура вычисления ответа на запрос напоминает функционирование конечного автомата. Мы начинаем с пустого состояния и при обработке каждого элемента запроса переходим в новое состояние, пока весь запрос не будет разобран. В основе нашей реализации лежит одна инструкция switch внутри операции, которую мы назвали eval_query(). Слова запроса считываются одно за другим из вектора строк и сравниваются с каждым из возможных значений:
 vector::iterator
  it = _query->begin(),
  end_it = _query->end();
 
 for ( ; it != end_it; ++it )
  switch( evalQueryString( *it ))
  {
  case WORD:
  evalWord( *it );
  break;
 
  case AND:
  evalAnd();
  break;
 
  case OR:
  evalOr();
  break;
 
  case NOT:
  evalNot();
  break;
 
  case LPAREN:
  ++_paren;
  ++_lparenOn;
  break;
 
  case RPAREN:
  --_paren;
  ++_rparenOn;
  evalRParen();
  break;
  }
 Пять операций eval: evalWord(), evalAnd(), evalOr(), evalNot и evalRParen() – как раз и строят иерархию классов Query. Прежде чем обратиться к деталям их реализации, рассмотрим общую организацию программы.
 Нам нужно определить каждую операцию в виде отдельной функции, как это было сделано в главе 6 при построении процедур обработки запроса. Пользовательский запрос и производные от Query классы представляют независимые данные, которыми оперируют эти функции. От такой модели программирования (она называется процедурной) мы предпочли отказаться.
 В разделе 6.14 мы ввели класс TextQuery, где инкапсулировали операции и данные, изучавшиеся в главе 6. Здесь нам потребуется класс UserQuery, решающий аналогичные задачи.
 Одним из членов этого класса должен быть вектор строк, содержащий сам запрос пользователя. Другой член – это указатель типа Query* на иерархическое представление запроса, построенное в eval_query(). Еще три члена служат для обработки скобок:
 _paren помогает изменить подразумеваемый порядок вычисления операторов (чуть позже мы продемонстрируем это на примере);
 _lparenOn и _rparenOn содержат счетчики левых и правых скобок, ассоциированные с текущим узлом дерева разбора запроса (мы показывали, как они используются, при обсуждении виртуальной функции print() в разделе 17.5.1).
 Помимо этих пяти членов, нам понадобятся еще два. Рассмотрим следующий запрос:
 
 fiery || untamed
 
 Наша цель – представить его в виде следующего объекта OrQuery:
 OrQuery
  NameQuery( "fiery" )
  NameQuery( "untamed" )
 Однако порядок обработки такого запроса вызывает некоторые проблемы. Когда мы определяем объект NameQuery, объект OrQuery , к которому его надо добавить, еще не определен. Поэтому необходимо место, где можно временно сохранить объект NameQuery.
 Чтобы сохранить что-либо для последующего использования, традиционно применяется стек. Поместим туда наш объект NameQuery. А когда позже встретим оператор ИЛИ (объект OrQuery), то достанем NameQuery из стека и присоединим его к OrQuery в качестве левого операнда.
 Объект OrQuery неполон: в нем не хватает правого операнда. До тех пор пока этот операнд не будет построен, работу с данным объектом придется прекратить.
 Его можно поместить в тот же самый стек, что и NameQuery. Однако OrQuery представляет другое состояние обработки запроса: это неполный оператор. Поэтому мы определим два стека: _query_stack для хранения объектов, представляющих сконструированные операнды составного запроса (туда мы помещаем объект NameQuery), а второй для хранения неполных операторов с отсутствующим правым операндом. Второй стек можно трактовать как место для хранения текущей операции, подлежащей завершению, поэтому назовем его _current_op. Сюда мы и поместим объект OrQuery. После того как второй объект NameQuery будет определен, мы достанем объект OrQuery из стека _current_op и добавим к нему NameQuery в качестве правого операнда. Теперь объект OrQuery завершен и мы можем поместить его в стек _query_stack.
 Если обработка запроса завершилась нормально, то стек _current_op пуст, а в стеке _query_stack содержится единственный объект, который и представляет весь пользовательский запрос. В нашем случае это объект класса OrQuery.
 Рассмотрим несколько примеров. Первый из них – простой запрос типа NotQuery:
 
 ! daddy
 
 Ниже показана трассировка его обработки. Финальным объектом в стеке _query_stack является объект класса NotQuery:
 evalNot() : incomplete!
  push on _current_op ( size == 1 )
 evalWord() : daddy
  pop _current_op : NotQuery
  add operand: WordQuery : NotQuery complete!
  push NotQuery on _query_stack
 Текст, расположенный с отступом под функциями eval, показывает, как выполняется операция.
  Во втором примере – составном запросе типа OrQuery – встречаются оба случая. Здесь же иллюстрируется помещение полного оператора в стек _query_stack:
 
 ==> fiery || untamed || shyly
 
 evalWord() : fiery

<< Пред.           стр. 86 (из 121)           След. >>

Список литературы по разделу