Примеры

Пример. Использование std::string в интерфейсе модуля. Пусть мы хотим, чтобы модуль предоставлял следующую функцию API:

std::string Translate(const std::string&);

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

Мы встречались с разработчиками, которые пытались использовать собственный класс-оболочку CustomString для объектов std::string, но в результате они сталкивались с той же проблемой, поскольку не имели полного контроля над процессом сборки всех клиентских приложений.

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

void Translate(const char* src, char* dest, size_t destSize);

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

Ссылки

[McConnell93] §6 • [Meyers01] §15

Шаблоны и обобщенность

Место для вашей цитаты.

— Бьярн Страуструп (Bjarne Stroustrup), [Stroustrup00] §13

Аналогично: место для вашего введения.

В этом разделе мы считаем наиболее значимой рекомендацию 64 — "Разумно сочетайте статический и динамический полиморфизм".

64. Разумно сочетайте статический и динамический полиморфизм

Резюме

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

Обсуждение

Динамический полиморфизм предстает перед нами в форме классов с виртуальными функциями и объектов, работа с которыми осуществляется косвенно — через указатели или ссылки. Статический полиморфизм включает шаблоны классов и функций.

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

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

Динамический полиморфизм позволяет значению иметь несколько типов посредством открытого наследования. Например, Derived* p можно рассматривать как указатель не только на Derived, но и на объект любого типа Base, который прямо или косвенно является базовым для Derived (свойство категоризации). Динамический полиморфизм известен также как включающий полиморфизм, поскольку множество, моделируемое Base, включает специализации, моделируемые Derived.

Благодаря своим характеристикам динамический полиморфизм в С++ наилучшим образом подходит для решения следующих задач.

• Единообразная работа, основанная на отношении надмножество/подмножество. Работа с различными классами, удовлетворяющими отношению надмножество/подмножество (базовый/производный), может выполняться единообразно. Функция, работающая с объектом Employee (Служащий), будет работать и с объектами Secretary (Секретарь).

• Статическая проверка типов. В С++ все типы проверяются статически.

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

• Бинарная согласованность. Модули могут компоноваться как статически, так и динамически, до тех пор, пока схемы виртуальных таблиц подчиняются одним и тем же правилам.

Статический полиморфизм посредством шаблонов также позволяет значению иметь несколько типов. Внутри шаблона

template<class T> void f(T t) { /* ... */ }

t может иметь любой тип, который можно подставить в f для получения компилируемого кода. Это называется "неявным интерфейсом" в противоположность явному интерфейсу базового класса. Таким образом достигается та же цель полиморфизма — написание кода, который работает с разными типами — но совершенно иным путем.

Статический полиморфизм наилучшим образом подходит для решения следующих задач.

• Единообразная работа, основанная на синтаксическом и семантическом интерфейсе. Работа с типами, которые подчиняются синтаксическому и семантическому интерфейсу, может выполняться единообразно. Интерфейсы в данном случае представляют синтаксическую сущность и не основаны на сигнатурах, так что допустима подстановка любого типа, который удовлетворяет данному синтаксису. Например, пусть дана инструкция int i = p->f(5);. Если p — указатель на класс Base, эта инструкция вызывает определенную функцию интерфейса, вероятно, virtual int f(int). Но если p имеет обобщенный тип, то этот вызов может быть связан со множеством различных вещей, включая, например, вызов перегруженного оператора operator->, который возвращает тип, в котором определена функция X f(double), где X — тип, который может быть преобразован в int.

• Статическая проверка типов. Все типы проверяются статически.

• Статическое связывание (мешает раздельной компиляции). Все типы связываются статически.

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

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

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

• Статика помогает динамике. Используйте статический полиморфизм для реализации динамически полиморфных интерфейсов. Например, у вас может быть абстрактный базовый класс Command, и вы определяете различные реализации в виде шаблона

template</* ... */> class ConcreteCommand: public Command

В качестве примеров можно привести реализации шаблонов проектирования Command и Visitor (см. [Alexandrescu01] и [Sutter04]).

• Динамика помогает статике. Обобщенный, удобный, статически связываемый интерфейс может использовать внутреннюю динамическую диспетчеризацию, что позволяет обеспечить одинаковую схему размещения объектов. Хорошими примерами могут служить реализации размеченных объединений (см. [Alexandrescu02b] и [Boost]) и параметр Deleter у tr1::shared_ptr (см. [C++TR104]).

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

Ссылки

[Alexandrescu01] §10 • [Alexandrescu02b] • [C++TR104] • [Gamma95] • [Musser01] §1.2-3, §17 • [Stroustrup00] §24.4.1 • [Sutter00] §3 • [Sutter02] §1 • [Sutter04] §17, §35 • [Vandevoorde03] §14 • [Webber03] §8.6