https://stiffstream.com/ru/news/2018/7/eao197_cpp_russia_2018.html

Здесь на форуме один C++-к развязал прямо-таки священную войну неверным (т.е. замеченным в связях с другими языками).

У меня к господину eao197 есть вопросы по его фреймворку.
— Зачем понадобилось делать фреймворк для банальной очереди сообщений?
— Зачем было слепо копировать модель акторов в C++, а не воспользоваться erlang-м, в котором это из коробки.
— Зачем кому-то вообще метрика с числом сообщений внутри процесса?
— Почему не писать на Go, в конце концов?

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

Тё>У меня к господину eao197 есть вопросы по его фреймворку.
Тё>- Зачем понадобилось делать фреймворк для банальной очереди сообщений?

Если ты не заметил, у нас (в C++ мире) нет ни CSP, ни Акторов и это очень печально. Лично я про Акторов не сильно переживаю, но вот отсутствие CSP сильно портит жизнь.

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

Тё>У меня к господину eao197 есть вопросы по его фреймворку.

Господина eao197 на RSDN нет. Под ником so5team здесь пишет тот или иной участник команды разработки SObjectizer/RESTinio, в зависимости от темы обсуждения и фазы луны. Если хотите пообщаться песонально с eao197, то можете сделать это, например, через его блог или профиль на Хабре.

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

Автор: so5team
Дата: 11.05.17

.

Тё>- Зачем понадобилось делать фреймворк для банальной очереди сообщений?

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

Тё>- Зачем было слепо копировать модель акторов в C++, а не воспользоваться erlang-м, в котором это из коробки.

SObjectizer -- это не копирование Модели Акторов. А Erlang, как можно судить по воспоминаниям Джо Армстронга, создавался вообще без оглядки на оную. Воспользоваться Erlang-ом можно, если вам задача это позволяет. Если не позволяет (например, вам нужна высокая производительность обработки данных или вы работаете с огромным C++ легаси), то вам приходится оставаться в мире C++.

Но так как этот вопрос задается постоянно, то лучше сошлемся на более развернутый ответ на этот вопрос.

Тё>- Зачем кому-то вообще метрика с числом сообщений внутри процесса?

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

Раз уж вы ссылаетесь на Erlang, то поинтересуйтесь у Erlang-еров, насколько у них ценятся средства интроспекции Erlang-овой VM, в частности, возможность мониторить размеры очередей процессов.

Тё>- Почему не писать на Go, в конце концов?

Когда SObjectizer появился, Go еще не было. Сейчас ситуация такая же, как и с Erlang-ом: если у вас нет необходимости оставаться в рамках C++, то можете использовать Go. Если же нужно сидеть в C++, то можно использовать механизмы CSP с помощью SObjectizer-а.

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

Здравствуйте, so5team, Вы писали:

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

Он был бы нужен нам, узнай я про него раньше Правда использование RTTI ставит крест на этом фреймворке, у нас RTTI отключено.
А так запилили своё, но похожее.

Здравствуйте, Stanislav V. Zudin, Вы писали:

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

А исключения используются?

Здравствуйте, so5team, Вы писали:

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

S>А исключения используются?

Используются в умеренных дозах.

Здравствуйте, Stanislav V. Zudin, Вы писали:

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

S>>А исключения используются?

SVZ>Используются в умеренных дозах.

Довольно странно, т.к. для нормальной работы исключений (например, для поимки исключения по ссылке на базовый класс) RTTI вроде как обязателен. Или вы std::exception вообще не применяете для исключений?

Тем не менее, в последние годы вопросы о возможности применения SObjectizer-а в условиях запретов на RTTI/exceptions/dynamic memory стали задавать чаще, чем лет 5-7 назад. Кое-кто уже даже озадачился проработкой этой темы. Но на данный момент адаптация SObjectizer-а к таким условиям выглядит слишком далекой перспективой.

Здравствуйте, so5team, Вы писали:


S>>>А исключения используются?
SVZ>>Используются в умеренных дозах.

S>Довольно странно, т.к. для нормальной работы исключений (например, для поимки исключения по ссылке на базовый класс) RTTI вроде как обязателен. Или вы std::exception вообще не применяете для исключений?

Не, эти механизмы вообще никак не связаны. std::exception и его производные отлично летают без RTTI. Это dynamic_cast без RTTI не работает

S>Тем не менее, в последние годы вопросы о возможности применения SObjectizer-а в условиях запретов на RTTI/exceptions/dynamic memory стали задавать чаще, чем лет 5-7 назад. Кое-кто уже даже озадачился проработкой этой темы. Но на данный момент адаптация SObjectizer-а к таким условиям выглядит слишком далекой перспективой.

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Не, эти механизмы вообще никак не связаны. std::exception и его производные отлично летают без RTTI. Это dynamic_cast без RTTI не работает

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

SVZ>У вас RTTI используется в качестве рабочего механизма. Безболезненно его выпилить — та еще задачка.

Ирония в том, что изначально RTTI был нужен из-за отсутствия variadic templates в имевшихся у нас компиляторах, и как следствие, невозможности написания шаблонной функции send. После появления шаблонного send-а появилась возможность обойтись без dynamic_cast-а при диспетчеризации сообщений. А это основная ниша для RTTI.

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

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

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

В общем, на тему сабжевого вопроса. Совсем свежее из соседнего форума: http://rsdn.org/forum/cpp.applied/7276592

Автор: niXman
Дата: 18.10.18

Здравствуйте, so5team, Вы писали:

S>В общем, на тему сабжевого вопроса. Совсем свежее из соседнего форума: http://rsdn.org/forum/cpp.applied/7276592

Автор: niXman
Дата: 18.10.18

Челу нужна событийная модель. Это https://www.github.com/Reactive-Extensions/RxJS. Не смотрел, есть ли такое для плюсов- для жавы оно (у меня) глючило, а в ангуларе (и в ноде) работает замечательно.

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

S>>В общем, на тему сабжевого вопроса. Совсем свежее из соседнего форума: http://rsdn.org/forum/cpp.applied/7276592

Автор: niXman
Дата: 18.10.18

Тё>Челу нужна событийная модель.

Вас может удивить, но именно это он и получил взяв SObjectizer. Событийную модель.

Тё>Это https://www.github.com/Reactive-Extensions/RxJS. Не смотрел, есть ли такое для плюсов- для жавы оно (у меня) глючило, а в ангуларе (и в ноде) работает замечательно.

Reactive Programming -- это одна из форм обработки событий, подходящая далеко не для всех сценариев, где "событийные модели" используются.
Но, в том числе, реактивные потоки можно делать в C++, в том числе и на базе SObjectizer-а.
В частности, он этом говорил Иван Чукич на Meeting C++ 2016: https://youtu.be/a2MmURgc6cU?t=2522
А как это может быть реализовано показывается в одном из наших штатных примеров. В частности, вот создание пайплайна, в котором события распространяются по подобию Rx-ных фреймворков:

auto pipeline = make_pipeline( *this,
        src | stage(validation) | stage(conversion) | broadcast(
            src | stage(archivation),
            src | stage(distribution),
            src | stage(range_checking) | stage(alarm_detector{}) | broadcast(
                src | stage(alarm_initiator),
                src | stage( []( const alarm_detected & v ) {
                        alarm_distribution( cerr, v );
                    } )
                )
            ),
        autoname );

Ответ на вопрос из subj: "Если проект «Театр» используй акторов…"