- -
- 100%
- +
С классом Executor3 ситуация еще интереснее, поскольку он использует множественное наследование6. Мы не можем напрямую назначать указатели на методы базового класса, как это приведено в строках 7 и 8, потому что если взглянуть на иерархию наследования, то можно увидеть, что к базовому классу можно добраться двумя путями – через Executor1 либо через Executor2. Таким образом, компилятор не знает, по какому пути выполнять поиск методов, и выдает ошибку. По указанной причине мы должны явно указать в цепочке наследования класс-предшественник. Если в пути наследования какая-нибудь функция окажется переопределена, то она будет вызвана, в противном случае будет вызвана функция базового класса.
В строке 9 мы в качестве предшественника указываем класс Executor1 и назначаем указатель на метод callbackHandler1. В Executor1 этот метод переопределен, и он будет вызван. В строке 10 мы назначаем указатель на метод callbackHandler2; в Executor1 этот метод не переопределен, поэтому будет вызван метод базового класса Executor::callbackHandler2. Если мы в качестве предшественника будем указывать Executor2, как это показано в строках 11 и 12, то получится все наоборот: в строке 11 будет вызван метод базового класса Executor:: callbackHandler1, а в строке 12 будет вызван соответствующий переопределенный метод Executor2::callbackHandler2.
Для наглядности сведем результаты в Табл. 3.
Табл. 3. Вызовы методов по цепочке наследования
Используя рассмотренные способы управления контекстом, можно реализовать довольно изощренную логику обработки и динамически ее изменять в процессе выполнения программы.
2.3.5. Синхронный вызов
Реализация инициатора для синхронного вызова представлена в Листинг 14. В отличие от асинхронного вызова, здесь аргументы не хранятся, а передаются как входные параметры функции.
Листинг 14. Инициатор для синхронного обратного вызова с указателем на метод-член классаclass Executor;
using ptr_method_callback_t = void(Executor::*)(int);
void run(Executor* ptrClientCallbackClass, ptr_method_callback_t ptrClientCallbackMethod)
{
int eventID = 0;
//Some actions
(ptrClientCallbackClass->*ptrClientCallbackMethod)(eventID);
}
2.3.6. Преимущества и недостатки
Преимущества и недостатки реализации обратных вызовов с помощью указателя на метод – член класса приведены в Табл. 4.
Табл. 4. Преимущества и недостатки реализации обратных вызовов с помощью указателя на метод-член класса
Гибкость. Управлять контекстом можно тремя способами, подобные возможности отсутствуют в других реализациях.
Отсутствие трансляции контекста. Контекст транслировать не нужно, метод-член имеет полный доступ к содержимому класса.
Сложность. Код получается довольно громоздким и запутанным.
Тип класса должен объявляться в инициаторе. Здесь достаточно только предварительного объявления класса. Полное объявление класса в инициаторе делать необязательно и даже нежелательно, потому что логически это обработчик обратного вызова, то есть он относится к исполнителю и должен быть в нем реализован. Тем не менее, требование предварительного объявления класса ограничивает независимость исполнителя: он может использовать только те типы классов, которые были предварительно объявлены в инициаторе.
Инициатор должен хранить указатель на метод и указатель на класс. Увеличивается расход памяти.
2.4. Функциональный объект
2.4.1. Концепция
С точки зрения C++ функциональный объект – это класс, который имеет перегруженный оператор вызова функции7.
Графическое изображение обратного вызова с помощью функционального объекта представлено на Рис. 14. Исполнитель реализуется в виде класса, код упаковывается в перегруженный оператор вызовы функции, в качестве контекста выступает экземпляр класса. При настройке экземпляр класса как аргумент сохраняется в инициаторе8. Инициатор осуществляет обратный вызов посредством вызова перегруженного оператора, передавая ему требуемую информацию. Контекст здесь передавать не нужно, поскольку внутри оператора доступно все содержимое класса.
Рис. 14. Реализация обратного вызова с помощью функционального объекта.
2.4.2. Инициатор
Предварительно необходимо объявить функциональный объект (см. Листинг 15), потому что его объявление должен видеть как инициатор, так и исполнитель.
Листинг 15.Объявление функционального объектаclass CallbackHandler
{
public:
void operator() (int eventID) //This is an overloaded operator
{
//It will be called by server
};
};
Реализация инициатора приведена в Листинг 16.
Листинг 16. Инициатор с функциональным объектомclass Initiator // (1)
{
public:
void setup(const CallbackHandler& callback) // (2)
{
callbackObject = callback;
}
void run() // (3)
{
int eventID = 0;
//Some actions
callbackObject(eventID); // (4)
}
private:
CallbackHandler callbackObject; // (5)
};
В строке 1 мы объявляется класс-инициатор. В строке 2 объявляется функция для настройки вызова, в которую передается ссылка на функциональный объект. Данный объект присваивается переменной-аргументу, объявленному в строке 5. В строке 3 объявлена функция запуска, внутри этой функции в строке 4 производится вызов перегруженного оператора. Как видим, синтаксис вызова перегруженного оператора совпадает с синтаксисом вызова обычной функции.
2.4.3. Исполнитель
Реализация исполнителя приведена в Листинг 17.
Листинг 17. Исполнитель с функциональным объектомint main()
{
Initiator initiator; // (1)
CallbackHandler executor; // (2)
initiator.setup(executor); // (3)
initiator.run(); // (4)
}
В строке 1 объявляется переменная класса-инициатора, в строке 2 объявляется функциональный объект, в строке 3 производится настройка, в строке 4 – запуск.
2.4.4. Синхронный вызов
Реализация инициатора для синхронного вызова представлена в Листинг 18. В отличие от асинхронного вызова, здесь функциональный объект не сохраняется как аргумент, он передается через входные параметры функции.
Листинг 18. Инициатор для синхронного вызова с функциональным объектомvoid run(CallbackHandler& callbackObject)
{
int eventID = 0;
//Some actions
callbackObject(eventID);
}
2.4.5. Преимущества и недостатки
Преимущества и недостатки реализации обратных вызовов с помощью функционального объекта приведены в Табл. 5.
Табл. 5. Преимущества и недостатки обратных вызовов с помощью функционального объекта
Простая реализация. Самая простая из всех рассмотренных. Необходима только одна переменная – экземпляр класса, весь контекст хранится внутри этого класса. Прозрачный и понятный синтаксис.
Безопасность. При настройке в инициаторе создается копия переданного функционального объекта. Исходный экземпляр становится ненужным, его можно безопасно удалить.
Отсутствие трансляции контекста. Код вызова хранится внутри перегруженного оператора, контекст инкапсулирован внутри класса вместе с кодом.
Общий функциональный объект. Инициатор и исполнитель связаны через единый функциональный объект, они оба должны видеть его объявление. Вся логика обработки реализуется внутри объекта. Это приводит к монолитной архитектуре, что сильно затрудняет модификацию поведения обработчика. По сути дела, исполнитель встраивается в инициатор и становится его составной частью9.
Невозможность реализации API. Следствие монолитной архитектуры: использование API предполагает возможность модификации поведения исполнителя без изменения кода инициатора. Поскольку они оба связаны через единый объект, выполнение указанного требования является нереализуемым.
Высокое быстродействие. А вот здесь недостатки монолитной архитектуры превращаются в достоинства. Дело в том, что поскольку инициатор сохраняет у себя объект, он имеет доступ к коду перегруженного оператора, т. е. к коду обработчика вызова. Как следствие, оптимизирующий компилятор получает возможность встроить код обработчика непосредственно в точку вызова, опуская вызов функции (перегруженный оператор тоже является функцией), что значительно ускоряет выполнение вызова. Рассмотрим этот момент подробнее.
2.4.6. Производительность
С точки зрения машинных команд, вызов функции – не слишком быстрая операция. Необходимо несколько команд для сохранения стека10; команда перехода к коду функции; команда возврата управления; несколько команд для восстановления стека. А если код тела функции небольшой, к примеру, всего лишь сравнение двух величин, то время, затраченное на вызов функции, может значительно превысить время выполнения кода функции.
Поясним сказанное на примере. Напишем маленькую простую программу, которая считывает из консоли два числа, складывает их и результат выводит на экран (Листинг 19).
Листинг 19. Маленькая простая программа#include
int Calculate(int a, int b)
{
return a + b;
}
int main()
{
int a, b;
std::cin >> a >> b;
int result = Calculate(a, b);
std::cout << result;
}
Откомпилируем код с выключенной оптимизацией и запустим на выполнение. Посмотрим дизассемблерный участок кода 11, в котором производится вызов функции (Листинг 20):
Листинг 20. Дизассемблерный код с выключенной оптимизацией:int Calculate(int a, int b)
{
00007FF6DA741005 and al,8 // 1
return a + b;
00007FF6DA741008 mov eax,dword ptr [b] // 2
00007FF6DA74100C mov ecx,dword ptr [a] // 3
00007FF6DA741010 add ecx,eax // 4
00007FF6DA741012 mov eax,ecx // 5
}
00007FF6DA741014 ret // 6
int main()
{
…….
int result = Calculate(a, b);
00007FF6DA741053 mov edx,dword ptr [b] // 7
00007FF6DA741057 mov ecx,dword ptr [a] // 8
00007FF6DA74105B call Calculate (07FF6DA741000h) // 9
00007FF6DA741060 mov dword ptr [result],eax // 10
…….
В строках 7 и 8 введенные значения a и b сохраняются в регистрах. В строке 9 выполняется вызов функции. В строке 1 выполняется обнуление результата, в строках 2 и 3 переданные значения копируются в регистры, в строке 4 выполняется сложение, в строке 5 результат копируется обратно в регистр, в строке 6 выполняется выход из функции, в строке 10 результат вычисления функции копируется в переменную результата.
Теперь включим оптимизацию, откомпилируем и посмотрим на код (Листинг 21):
Листинг 21. Дизассемблерный код с включенной оптимизациейint main()
{
…….
int result = Calculate(a, b);
00007FF7D5B11033 mov edx,dword ptr [b]
00007FF7D5B11037 add edx,dword ptr [a]
Как видим, для вычислений у нас всего две операции: запись в регистр значения b и добавление к нему значения a. Код встроен в поток выполнения, вызов функции не производится. Ощутимая разница, не правда ли?
2.5. Лямбда-выражение
2.5.1. Концепция
Лямбда-выражение12 – это локальная неименованная функция, которая, подобно обычной функции, может принимать входные параметры и возвращать результат. Особенностью лямбда-выражений, отличающих их от обычных функций, является возможность захвата переменных.
Графическое изображение обратного вызова с помощью лямбда-выражения представлено на Рис. 15. Исполнитель реализуется в виде какой-либо исполняемой функции, в качестве которой могут выступать глобальная функция, статический метод класса, метод-член класса, перегруженный оператор. Код обратного вызова упаковывается в лямбда-выражение, в качестве контекста выступают захваченные переменные. При настройке лямбда-выражение как аргумент сохраняется в инициаторе. Инициатор осуществляет обратный вызов посредством вызова хранимого выражения, передавая ему требуемую информацию. Контекст здесь передавать не нужно, поскольку внутри тела лямбда-выражения доступны все захваченные переменные.
Рис. 15. Реализация обратного вызова с помощью лямбда-выражения
2.5.2. Инициатор
Как хранить и передавать лямбда-выражение как аргумент? Если оно не захватывает переменные, то стандарт допускает неявное преобразование лямбда-выражения к указателю на функцию. В этом случае реализация инициатора полностью совпадает с рассмотренной в 2.1. Однако использование лямбда-выражений без захвата переменных не дает никакого преимущества по сравнению с обычной функцией, использовать их в таком виде не имеет смысла.
Другое дело, когда лямбда-выражение осуществляет захват переменных, в этом случае мы получаем мощный и гибкий инструмент управления контекстом. Однако использование таких выражений в качестве аргумента вызывает определенные сложности. Связано это с тем, что тип лямбда-выражения является анонимным. Как следствие, имя типа нам неизвестно, и мы не можем просто объявить переменную нужного типа и присвоить ей лямбда-выражение, как это происходит, например, с указателями или классами. Решается указанная проблема с помощью шаблонов, что будет рассмотрено позже в соответствующих главах. Забегая вперед, отметим, что для хранения лямбда-выражений можно объявлять шаблон с параметром – типом лямбда-выражения (п. 4.4.2) либо использовать специальные классы библиотеки STL (п. 4.6.1).
2.5.3. Исполнитель
Исполнитель реализовывается в виде лямбда-выражения, а передача его как аргумента инициатору зависит от способа реализации последнего. Если исполнитель реализован в виде шаблона класса (п. 4.4.2), лямбда-выражение должно присваиваться в конструкторе класса. В случае использования классов STL (п. 4.5.1) лямбда-выражение передается подобно любому другому аргументу. Подробно эти вопросы рассматриваются в разделе 4, посвященном использованию шаблонов.
2.5.4. Синхронный вызов
Инициатор для синхронного вызова с лямбда-выражением реализуется в виде шаблонной функции, параметром шаблона выступает тип аргумента. Подробно этот вопрос рассмотрен в п. 4.2.1.
2.5.5. Преимущества и недостатки
Преимущества и недостатки реализации обратных вызовов с помощью лямбда-выражения приведены в Табл. 6.
Табл. 6. Преимущества и недостатки обратных вызовов с помощью лямбда-выражения
Гибкое управление контекстом. Возможность захвата переменных предоставляет простые и удобные средства изменения контекста. Изменяя состав захваченных переменных, мы легко можем добавлять значения, необходимые для контекста, при этом нет необходимости изменять код инициатора. Захватив указатель this, мы получаем доступ к содержимому класса, т. е. фактически лямбда-выражение превращается в «метод внутри метода» (см. пример в Листинг 22). Элегантно, не правда ли?
Требует использования шаблонов. Использование шаблонов накладывает архитектурные ограничения на реализацию программных модулей. Это связанно с тем, что шаблоны не предполагают присутствие предварительно откомпилированного кода. Подробнее об этом мы будем говорить в соответствующей главе (4.7), посвященной ограничениям при использовании шаблонов.
Листинг 22. Лямбда-выражение с захватом указателя thisclass EventCounter
{
public:
void AddEvent(unsigned int event)
{
callCounter_++;
lastEvent_ = event;
}
private:
unsigned int callCounter_ = 0;
int lastEvent_ = 0;
};
class Executor
{
public:
Executor(EventCounter* counter): counter_(counter)
{
auto lambda = [this](int eventID)
{
//It will be called by initiator
counter_->AddEvent(eventID);
processEvent(eventID);
};
//Setup lambda in initiator
}
private:
EventCounter* counter_;
void processEvent(int eventID) {/*Do something*/}
};
2.6. Итоги
В C++ обратные вызовы могут быть реализованы с помощью следующих конструкций:
• указатель на функцию;
• указатель на статический метод класса;
• указатель на метод-член класса;
• функциональный объект;
• лямбда-выражение.
Каждая реализация имеет свои достоинства и недостатки. Так какую все-таки выбрать? Чтобы ответить на этот вопрос, необходимо выполнить сравнительный анализ.
3. Сравнительный анализ реализаций
3.1. Методологические подходы
3.1.1. Обобщенный алгоритм
Итак, мы рассмотрели различные способы реализации обратных вызовов. Какая из них наилучшим образом подходит для использования в конкретной ситуации? Чтобы ответить на этот вопрос, необходимо сравнить реализации, т. е. требуется сравнительный анализ.
Обобщенный алгоритм сравнительного анализа включает следующие шаги.
1. Выбрать объекты анализа.
2. Определить критерии сравнения.
3. Построить матрицу соответствия, в которой отобразить, насколько объекты анализа соответствуют выбранным критериям.
4. Проанализировать полученные результаты и выбрать объект, наилучшим образом удовлетворяющий совокупности критериев.
Рассмотрим указанные шаги подробнее.
1. Объект анализа – это некая сущность, которая будет подвергаться анализу. В нашем случае такими сущностями выступают реализации обратных вызовов.
2. Выбор критериев – пожалуй, самый сложный и в то же время наиболее важный этап сравнительного анализа. Критерии должны отражать значимость показателя, который они определяют; неверный выбор критериев приводит к неправильным результатам. Так, например, в качестве критерия можно выбрать количество строк кода, но насколько этот показатель значим при разработке? В нашем случае совершенно не значим: не имеет значения, займет реализация 10 или 50 строк, важно то, насколько она обеспечивает качество выполняемых функций. Качество, в свою очередь, определяется степенью выполнения требований, предъявляемых к проектируемой системе. По этой причине именно требования наилучшим образом подходят для использования в качестве критериев.
3. Матрица соответствия строится в виде таблицы. В заголовки строк таблицы вписываются критерии, в заголовки столбцов – объекты анализа. В ячейках таблицы для каждой пары «объект-критерий» выставляется степень соответствия объекта заданному критерию. Степень выполнения может быть качественной (выполняется/не выполняется) или количественной (выставляется оценка по заданной шкале).
4. Полученные результаты суммируются. Объект, набравший наибольшее количество положительных утверждений (качественная оценка), или наибольшее количество баллов (количественная оценка), будет оптимальным.
Итак, мы описали обобщенный алгоритм сравнительного анализа. Далее рассмотрим, как выполняются шаги алгоритма применительно к поставленной задаче – выбору оптимальной реализации для конкретного случая. Первый шаг – выбор объектов анализа – здесь тривиальный, объектами анализа являются реализации обратных вызовов. Перейдем ко второму шагу –определим критерии, в качестве которых выступают требования.
3.1.2. Требования как критерии
Обозначим требования, предъявляемые при разработке программного кода обратных вызовов. Состав требований не претендует на полноту, читатель может добавить свои, если посчитает их значимыми или актуальными для конкретного случая.
Простота. Показывает, насколько просто и быстро можно написать, отладить и сопровождать код.
Независимость компонентов. Показывает, нужно ли изменять код одного компонента при изменении другого. Чем меньше зависимости между компонентами (в нашем случае это инициатор и исполнитель), тем проще разработка и отладка программной системы. Кроме того, упрощается ее сопровождение и повышается надежность.
Отсутствие трансляции контекста. Отсутствие необходимости трансляции контекста упрощает разработку, улучшает прозрачность кода и повышает независимость компонентов. И наоборот, трансляция контекста усложняет код и заставляет инициатор выполнять дополнительные операции для хранения и передачи контекста
Безопасность. Показывает устойчивость системы к потенциальным ошибкам.
Гибкость. Показывает, насколько просто модифицировать код при появлении новых требований.
Полиморфизм. Показывает, поддерживается ли полиморфизм в реализации исполнителя. Поддержка полиморфизма упрощает разработку и повышает гибкость в рамках объектно-ориентированной парадигмы.
Быстродействие. Показывает, насколько быстро осуществляется вызов кода исполнителя.
Системный API. Показывает возможность реализации системных API.
C++ API. Показывает возможность реализации C++ API.
Итак, объекты анализа выбраны, критерии определены. Теперь нужно построить матрицу соответствия. Для начала мы будем использовать качественный анализ, поскольку он более простой в реализации.
3.2. Качественный анализ
3.2.1. Матрица соответствия
Матрица соответствия строится в виде таблицы. В строках выписываются требования, в столбцах – способы реализации, в ячейках – признаки, указывающие, насколько реализация поддерживает соответствующий критерий (Табл. 7.)
Табл. 7. Качественный анализ реализаций обратных вызовов
Легенда: ▪ полностью поддерживается; ▫ поддерживается частично; пустое поле – не поддерживается
По каким соображениям мы назначили оценки?
Простота. Самой сложной реализацией будет, пожалуй, указатель на метод-член класса: запутанный и не слишком наглядный синтаксис. Довольно сложной выглядит реализация лямбда-выражений, поскольку приходится использовать шаблоны. Несколько проще выглядит реализация с помощью указателей на функцию, но там немного запутывает необходимость приведения типов. На этом фоне остальные реализации выглядят достаточно простыми.
Независимость компонентов. Полностью независимыми будет реализация с помощью указателей на функцию: как бы мы не модифицировали код исполнителя, как бы не меняли используемый контекст, код инициатора остается неизменным, даже не требуется его перекомпиляция. Это одна из причин, почему указанная реализация подходит для построения системных API. Лямбда-выражения являются относительно независимыми: при любом изменении состава и типов захваченных переменных код инициатора остается неизменным, но он будет требовать перекомпиляции, поскольку реализован с использованием шаблонов. Указатели на методы классов являются частично независимыми, поскольку требуют предварительного объявления класса в инициаторе. Использование функциональных объектов порождает монолитную архитектуру, где инициатор и исполнитель зависят друг от друга.
Отсутствие трансляции контекста. Указатели на функции и статические методы требуют трансляции контекста, остальные реализации этого не требуют.