Обратные вызовы в C++ [заметки]

Шрифт

Интервал

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

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

В качестве примера можно привести практику моделирования embedded-систем. В самом общем виде Embedded-системы представляют собой микроконтроллер, который встраивается в какое-либо устройство и выполняет функции управления, мониторинга и контроля. В силу определенных причин так сложилось, что ПО для управляющих контроллеров (такое ПО называют firmware) пишется на языке C. В процессе разработки подобных устройств часто используется моделирование, когда firmware запускается на обычном компьютере в имитационном окружении, а реальные аппаратные устройства заменяются их программными моделями. Модели и имитаторы обычно пишутся на языке C++, а firmware, как правило, написано на C – получается смешанный код.

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

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

Другое название, которое встречается в литературе, – функтор.

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

Частично этот недостаток устраняется с помощью шаблонов, что будет рассматриваться в соответствующем разделе.

Количество таких команд зависит от количества входных параметров функции.

Этот код получен с помощью компилятора Microsoft Visual studio версии 19.23.28106.4. Другие компиляторы могут генерировать отличающийся код, но принцип останется прежним.

В литературе можно встретить термин «лямбда-функция», но в стандарте С++ он именуется как “lambda-expression”, что в переводе означает «лямбда-выражение».

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

Минимальное отрицательное, по модулю оно будет максимальным.

Мы говорим «меньше», поскольку числа здесь отрицательные. По модулю это значение будет «больше».

В противоположность полиморфизму подтипов, который подразумевает исполнение потенциально разного кода для каждого типа или подтипа. В C++ полиморфизм подтипов реализуется с помощью наследования и виртуальных функций.

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

Для изучения можно порекомендовать книгу «Вандевурд, Джосаттис, Грегор. Шаблоны C++: справочник разработчика», где подробно рассматриваются соответствующие темы.

Здесь функциональный объект реализует паттерн «адаптер». Для знакомства с паттернами вообще, и с паттерном «адаптер» в частности можно порекомендовать книгу « Гамма Э., Хелм Р., Джонсон Р., Влиссидес Д. Приемы объектно-ориентированного проектирования. Паттерны проектирования».

Мы употребили термин «частично», потому что полной независимости здесь нет: при изменении функционального объекта нужно перекомпилировать как инициатор, так и исполнитель. Таким образом, независимость здесь обеспечивается только на уровне исходного кода.

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

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

Для фундаментального изучения техники стирания типов можно порекомендовать книгу «Пикус Ф.Г.

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

На момент написания книги это C++ 20.

«Зачем же мы тогда разрабатывали универсальный аргумент, если в STL все уже давно реализовано?» – может воскликнуть рассерженный читатель. Ну, во-первых, грамотный разработчик отличается от обычного разработчика тем, что он не только знает, как применять те или иные инструменты, но еще и понимает, как они работают. И, во-вторых, рассмотренные методы используются не только в проектировании обратных вызовов, они могут использоваться при решении самых различных задач.

Исходный код можно посмотреть здесь: .

Указатели на статические методы классов в эксперименте не участвовали, потому что с точки зрения организации вызова они идентичны указателям на обычные функции. Профилирование выполнялось в среде Microsoft Visual Stidio.

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

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

Снижается время выполнения – увеличивается быстродействие, т. е. эти показатели обратно пропорциональны.

Здесь необходимо уточнить: речь идет только об интерфейсе API, т. е. его видимой части. В реализации API шаблоны использовать можно и нужно.

Но не шаблон класса, в шаблонах классов пакет параметров может быть только один. Кроме того, если в шаблоне объявляется пакет параметров, он должен быть последним в списке параметров шаблона.

Это связано с тем, что функция получения элемента кортежа по индексу объявлена как шаблон с параметром – числовым значением. Переменные не могут выступать параметрами шаблона.

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

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

1) нарушается важнейший принцип проектирования – разделение интерфейса и реализации. Мы жестко завязываемся на структуру хранения объектов вызовов, поэтому архитектура получается монолитной;

2) идентификаторы объектов не несут никакой смысловой нагрузки, это просто некие абстрактные значения;

3) идентификаторы не детерминированы, при добавлении объекта в контейнер идентификатор получит произвольное значение;

4) идентификаторам объектов невозможно назначить заранее заданные значения;

5) в силу вышеуказанных причин невозможно реализовать логические протоколы обмена.

Контейнер std::map требует именно такой предикат, less, который возвращает истину в случае, если первый элемент меньше второго. Другие контейнеры могут требовать иные предикаты, например, проверку на равенство equal.

Диаграмма классов изображена в формате UML. Читателям, которые не знакомы с указанным графическим языком моделирования, можно порекомендовать книгу «Леоненков А. В. Самоучитель UML 2».

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