Правило 43: Необходимо знать, как обращаться к именам в шаблонных базовых классах

Правило 43: Необходимо знать, как обращаться к именам в шаблонных базовых классах

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

class CompanyA {

public:

...

void sendClearText(const std::string& msg);

void sendEncryptedText(const std::string& msg);

...

};

class CompanyB{

public:

...

void sendClearText(const std::string& msg);

void sendEncryptedText(const std::string& msg);

...

};

... // классы для других компаний

class MsgInfo {...}; // класс, содержащий информацию,

// используемую для создания

// сообщения

template<typename Company>

class MsgSender {

public:

... // конструктор, деструктор и т. п.

void sendClear(const MsgInfo& info)

{

std::string msg;

создать msg из info

Company c;

c.sendClearText(msg);

}

void sendSecret(const MsgInfo& info) // аналогично sendClear, но вызывает

{...} // c.sendEncrypted

};

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

template <typename Company>

class LoggingMsgSender: public MsgSender<Company> {

public:

...

void sendClearMsg(const MsgInfo& info)

{

записать в протокол перед отправкой;

sendClear(info); // вызвать функцию из базового класса

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

записать в протокол после отправки;

}

...

};

Отметим, что функция, отправляющая сообщение, в производном классе называется иначе (sendClearMsg), чем в базовом (sendClear). Это хорошее решение, потому что таким образом мы обходим проблему сокрытия унаследованных имен (см. правило 33), а равно сложности, возникающие при переопределении наследуемых невиртуальных функций (см. правило 36). Но этот код не будет компилироваться, по крайней мере, компилятором, совместимым со стандартом. Такой компилятор решит, что функции sendClear не существует. Мы видим, что эта функция определена в базовом классе, но компилятор не станет искать ее там. Попытаемся понять – почему.

Проблема в том, что когда компилятор встречает определение шаблона класса LoggingMsgSender, он не знает, какому классу тот наследует. Понятно, что классу MsgSender<Company>, но Company – параметр шаблона, который не известен до момента конкретизации LoggingMsgSender. Не зная, что такое Company, невозможно понять, как выглядит класс MsgSender<Company>. В частности, не существует способа узнать, есть ли в нем функция sendClear.

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

class CompanyZ { // этот класс не представляет

public: // функции sendCleartext

...

void sendEncrypted(const std::string& msg);

...

};

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

template <> // полная специализация MsgSender;

class MsgSender <CompanyZ> { // отличается от общего шаблона

public: // только отсутствием функции

... // sendCleartext

void sendSecret(const MsgInfo& info)

{...}

};

Обратите внимание на синтаксическую конструкцию «template<>» в начале определения класса. Она означает, что это и не шаблон, и не автономный класс. Это специализированная версия шаблона MsgSender, которая должна использоваться, если параметром шаблона является CompanyZ. Называется это полной специализацией шаблона : шаблон MsgSender специализирован для типа CompanyZ, и эта специализация применяется, коль скоро в качестве параметра указан тип CompanyZ, никакие другие особенности параметров шаблона во внимание не принимаются.

Имея специализацию шаблона MsgSender для CompanyZ, снова рассмотрим производный класс LoggingMsgSender:

template <typename Company>

class LoggingMsgSender: public MsgSender<Company> {

public:

...

void sendClearMsg(const MsgInfo& info)

{

записать в протокол перед отправкой;

sendClear(info); // если Company == CompanyZ,

// то этой функции не существует

записать в протокол после отправки;

}

...

};

Как следует из комментария, этот код просто не имеет смысла, если базовым классом является MsgSender<CompanyZ>, так как в нем нет функции sendClear. Поэтому C++ отвергнет такой вызов; компилятор понимает, что шаблон базового класса можно специализировать, и интерфейс, предоставляемый этой специализацией, может быть не таким, как в общем шаблоне. В результате компилятор обычно не ищет унаследованные имена в шаблонных базовых классах. В некотором смысле, когда мы переходим от «объектно-ориентированного C++» к «C++ с шаблонами» (см. правило 1), наследование перестает работать.

Чтобы исправить ситуацию, нужно как-то заставить C++ отказаться от догмы «не заглядывай в шаблонные базовые классы». Добиться этого можно тремя способами. Во-первых, можно предварить обращения к функциям из базового класса указателем this:

template <typename Company>

class LoggingMsgSender: public MsgSender<Company> {

public:

...

void sendClearMsg(const MsgInfo& info)

{

записать в протокол перед отправкой

;

this->sendClear(info); // порядок! Предполагается, что

// sendClear будет унаследована

записать в протокол после отправки

;

}

...

};

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

template <typename Company>

class LoggingMsgSender: public MsgSender<Company> {

public:

using MsgSender<Company>::sendClear; // сообщает компилятору о том, что

... // sendClear есть в базовом классе

void sendClearMsg(const MsgInfo& info)

{

...

sendClear(info); // нормально, предполагается, что

... // sendClear будет унаследована

}

...

};

Хотя using-объявление будет работать как здесь, так и в правиле 33, но используются они для решения разных задач. Здесь проблема не в том, что имена из базового класса скрыты за именами, объявленными в производном классе, а в том, что компилятор вообще не станет производить поиск в области видимости базового класса, если только вы явно не попросите его об этом.

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

template <typename Company>

class LoggingMsgSender: public MsgSender<Company> {

pubilc:

...

void sendClearMsg(const MsgInfo& info)

{

...

MsgSender<Company>::sendClear(info); // нормально, предполагается, что

... // sendClear будет унаследована

}

...

};

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

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

LoggingMsgSender<CompanyZ> zMsgSender;

MsgInfo msgData;

... // поместить info в msgData

zMsgSender.sendClearMsg(msgData); // ошибка! не скомпилируется

то вызов sendClearMsg не скомпилируется, потому что в этой точке компилятор знает, что базовый класс – это специализация шаблона MsgSender<CompanyZ> и в нем нет функции sendClear, которую sendClearMsg пытается вызвать.

Таким образом, суть дела в том, когда компилятор диагностирует неправильные обращения к членам базового класса – раньше (когда анализируются определения шаблонов производного класса) или позже (когда эти шаблоны конкретизируются переданными в шаблон аргументами). C++ предпочитает раннюю диагностику, и поэтому предполагает, что о содержимом базовых классов, конкретизируемых из шаблонов, не известно ничего.

Что следует помнить

• В шаблонах производных классов ссылки на имена из шаблонов базовых классов осуществляются с помощью префикса «this->», using-объявления либо посредством явного указания базового класса.

Данный текст является ознакомительным фрагментом.



Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

Когда следует обращаться в компанию по разработке сайтов

Из книги автора

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


Специализация шаблонных функций – членов шаблонного класса

Из книги автора

Специализация шаблонных функций – членов шаблонного класса К сожалению, вышеприведенный код не будет компилироваться на компиляторах, не поддерживающих специализацию шаблонов-функций – членов шаблонов классов.ПРИМЕЧАНИЕ К таким относятся, например, gcc-2.95 и gcc-2.96


1.6.5. Правило простоты: необходимо проектировать простые программы и "добавлять сложность" только там, где это необходимо

Из книги автора

1.6.5. Правило простоты: необходимо проектировать простые программы и "добавлять сложность" только там, где это необходимо Многие факторы приводят к усложнению программ (а следовательно, делают их более дорогими и более уязвимыми относительно ошибок). Программисты — это


1.6.5. Правило простоты: необходимо проектировать простые программы и "добавлять сложность" только там, где это необходимо

Из книги автора

1.6.5. Правило простоты: необходимо проектировать простые программы и "добавлять сложность" только там, где это необходимо Многие факторы приводят к усложнению программ (а следовательно, делают их более дорогими и более уязвимыми относительно ошибок). Программисты — это


6. Модификация базовых отношений

Из книги автора

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


Обеспечение поддержки подписывания объектов в ваших классах

Из книги автора

Обеспечение поддержки подписывания объектов в ваших классах Традиционно при необходимости доступа к объектам, содержащимся в коллекциях — например, массивах и словарях, — программисту требовалось получить доступ к методу в словаре или массиве, чтобы получить или


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

Из книги автора

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


Пример. Простановка базовых размеров

Из книги автора

Пример. Простановка базовых размеров Проставьте линейный размер, а затем от него – базовые (рис. 10.15). Рис. 10.15. Простановка базовых размеровЗапустите команду DIMLINEAR, вызвав ее из меню Dimension ? Linear или щелчком на пиктограмме Linear на панели инструментов Dimension. Ответьте на


Вызов шаблонных правил

Из книги автора

Вызов шаблонных правил Рассмотрим следующий простой пример.Листинг 5.1. Входящий документ<para><bold>text</bold></para>Попробуем написать пару шаблонов, которые будут изменять имена элементов para и bold на p и b соответственно. Сначала напишем преобразование для bold:<xsl:template


18.4.5. Прием потока ввода без применения шаблонных команд

Из книги автора

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


Глава 3. Что необходимо знать для понимания хакинга

Из книги автора

Глава 3. Что необходимо знать для понимания хакинга В этой главе я постараюсь очень кратко наметить то, что нужно знать хакеру и грамотному системному администратору, на которого легла задача по обеспечению безопасности сети. В рамках данного руководства невозможно


Еще раз о базовых классах

Из книги автора

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


Константы базовых типов

Из книги автора

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


У18.3 Однократные функции в родовых классах

Из книги автора

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