Здравствуйте, Тёмчик, Вы писали:

S>>Вот реально не понимаю, как паттерн Visitor поможет при работе с C API. Ладно бы еще какой-нибудь Facade был упомянут, ну или Bridge хотя бы, но Visitor... Просветите старика, плиз.
Тё>Дано: одно или несколько сторонних API. Нужно: сделать бесшовную интеграцию. Передаём visitor на нужное API. Это широко используемая практика в обработке данных от пачки разных API разных версий.

Понятнее не стало. Вот есть C API вида:

void * somelib_data_create();
void somelib_data_on_ready(void *);
void somelib_data_destroy(void *);

При нажатии на кнопку Ok нужно вызывать somelib_data_on_ready и передать в него указатель, полученный ранее при вызове somelib_data_destroy.

Каким образом здесь применим Visitor?

S>>По поводу накладных расходов все было уже расписано ранее, перечитайте. По поводу "мутно", если вам не понятно, то речь шла про понятность политки владения сущностями в вашем подходе. В C++ сборщика мусора нет. Возвращать голые владеющие указатели так себе способ.
Тё>Можете сделать умный указатель для subscription.

Этого будет мало.

Тё>Да, C++ это боль.

У вас, похоже, это была боль. Даже нет, у вас это была БОЛЬ. Причем такая, что отзывается до сих пор.

>>>> Реалтаймовые системы не на плюсах делают.

S>>Ответили за звиздеж, да.
Тё>Не на плюсах.

Вот опять звиздеж. Делают. В том числе и на современных. В том числе и с использованием кусков из STL. Ничего не мешает в рилтайм-коде использовать std::find, std::accumulate, std::array и подобный код. Да даже аллоцирующие контейнеры вроде vector, map, set можно применять, если они наполняются в момент инициализации приложения.

Если где-то до сих пор в рилтайме ограничиваются C++98, то, скорее всего, из-за отсутствия сертифицированных компиляторов с поддержкой более новых стандартов.

Тё>Вот вы влезли в тему событийной модели, которой я сейчас плотно занимаюсь (использую RxJs).

Да это очевидно, что сейчас у вас с RxJs конфетно-букетный период.