Сергей Шамбир, Адаптация Promise/A+ для взаимодействия между C++ и JavascriptSergey Platonov
Шаблоны — мощный инструмент, добавляющий в язык новые возможности, а программистам в команде — новые проблемы. Доклад покажет, как тщательно продуманный шаблонный код может не усложнить, а упростить жизнь и дать надёжную абстракцию межпроцессных межъязыковых асинхронных вызовов функций. С помощью шаблонов можно:
адаптировать Promise/A+ из Javascript для C++
автоматически проверять и раскладывать динамический массив аргументов на статичные аргументы функции
сделать аналог std::bind для weak_ptr.
Эти вещи будут показаны на примере взаимных вызовов между C++ и Javascript в одном приложении с помощью CEF3.
Полухин Антон, Как делать не надо: C++ велосипедостроение для профессионаловSergey Platonov
В докладе перед нами откроется великолепный мир велосипедов и устаревших технологий, которые люди продолжают переносить в новые проекты и повсеместно использовать. Мы поговорим о:
Copy-On-Write
разработке без оглядки на готовые решения и к чему это приводит
force inline
оптимизациях, которые отлично себя показывают на бенчмарках и плохо себя ведут в реальной жизни
бездумно отключаемых оптимизациях компилятора
тонкостях стандартной библиотеки для повседневного использования
супер качественном велосипедостроении
Евгений Зуев, С++ в России: Стандарт языка и его реализацияPlatonov Sergey
Доклад посвящён различным аспектам компилятора С++, созданного с участием автора. В выступлении рассказывается о продвинутой архитектуре компилятора, основных проектных решениях, а также обсуждаются особенности входного языка, повлиявшие на реализацию компилятора.
Евгений Рыжков, Андрей Карпов Как потратить 10 лет на разработку анализатора ...Platonov Sergey
Кто-то верно подметил, что разработчики статических анализатора часто сталкиваются с "проблемой айсберга". Им сложно объяснить разработчикам, почему сложно написать и развивать статические анализаторы кода. Дело в том, что сторонние наблюдатели видят только вершину всего процесса, так как им доступен для изучения только простой интерфейс, который предоставляют анализаторы для взаимодействия с миром. Это ведь не графический редактор с сотнями кнопок и рычажков. В результате и возникает ощущение, что раз прост интерфейс взаимодействия, то и прост продукт. На самом деле статические анализаторы кода — это сложные программы, в которых живут и взаимодействуют разнообразнейшие методы поиска дефектов. В них реализуется множество экспертные системы, выдающие заключения о коде на основе как точных, так и эмпирических алгоритмах. В парном докладе, основатели анализатора PVS-Studio расскажут о том, как незаметно потратить 10 лет, чтобы написать хороший анализатор. Дьявол кроется в деталях!
Дмитрий Кашицын, Троллейбус из буханки: алиасинг и векторизация в LLVMSergey Platonov
Зачастую, знакомство с алиасингом в C++ у многих программистов начинается и заканчивается одинаково: -fno-strict-aliasing. На вопросы новичка, более опытные коллеги отвечают в стиле: «не трогай! а то все сломаешь!». Новичок и не трогает. В докладе будет предпринята попытка заглянуть под капот и понять, что же там, внутри. Что такое алиасинг, где он может быть полезен и какие реальные преимущества дает. Тема будет рассмотрена и со стороны программиста и со стороны разработчика компилятора. А по сему, вопрос «зачем?» будет центральным в повествовании.
Сергей Шамбир, Адаптация Promise/A+ для взаимодействия между C++ и JavascriptSergey Platonov
Шаблоны — мощный инструмент, добавляющий в язык новые возможности, а программистам в команде — новые проблемы. Доклад покажет, как тщательно продуманный шаблонный код может не усложнить, а упростить жизнь и дать надёжную абстракцию межпроцессных межъязыковых асинхронных вызовов функций. С помощью шаблонов можно:
адаптировать Promise/A+ из Javascript для C++
автоматически проверять и раскладывать динамический массив аргументов на статичные аргументы функции
сделать аналог std::bind для weak_ptr.
Эти вещи будут показаны на примере взаимных вызовов между C++ и Javascript в одном приложении с помощью CEF3.
Полухин Антон, Как делать не надо: C++ велосипедостроение для профессионаловSergey Platonov
В докладе перед нами откроется великолепный мир велосипедов и устаревших технологий, которые люди продолжают переносить в новые проекты и повсеместно использовать. Мы поговорим о:
Copy-On-Write
разработке без оглядки на готовые решения и к чему это приводит
force inline
оптимизациях, которые отлично себя показывают на бенчмарках и плохо себя ведут в реальной жизни
бездумно отключаемых оптимизациях компилятора
тонкостях стандартной библиотеки для повседневного использования
супер качественном велосипедостроении
Евгений Зуев, С++ в России: Стандарт языка и его реализацияPlatonov Sergey
Доклад посвящён различным аспектам компилятора С++, созданного с участием автора. В выступлении рассказывается о продвинутой архитектуре компилятора, основных проектных решениях, а также обсуждаются особенности входного языка, повлиявшие на реализацию компилятора.
Евгений Рыжков, Андрей Карпов Как потратить 10 лет на разработку анализатора ...Platonov Sergey
Кто-то верно подметил, что разработчики статических анализатора часто сталкиваются с "проблемой айсберга". Им сложно объяснить разработчикам, почему сложно написать и развивать статические анализаторы кода. Дело в том, что сторонние наблюдатели видят только вершину всего процесса, так как им доступен для изучения только простой интерфейс, который предоставляют анализаторы для взаимодействия с миром. Это ведь не графический редактор с сотнями кнопок и рычажков. В результате и возникает ощущение, что раз прост интерфейс взаимодействия, то и прост продукт. На самом деле статические анализаторы кода — это сложные программы, в которых живут и взаимодействуют разнообразнейшие методы поиска дефектов. В них реализуется множество экспертные системы, выдающие заключения о коде на основе как точных, так и эмпирических алгоритмах. В парном докладе, основатели анализатора PVS-Studio расскажут о том, как незаметно потратить 10 лет, чтобы написать хороший анализатор. Дьявол кроется в деталях!
Дмитрий Кашицын, Троллейбус из буханки: алиасинг и векторизация в LLVMSergey Platonov
Зачастую, знакомство с алиасингом в C++ у многих программистов начинается и заканчивается одинаково: -fno-strict-aliasing. На вопросы новичка, более опытные коллеги отвечают в стиле: «не трогай! а то все сломаешь!». Новичок и не трогает. В докладе будет предпринята попытка заглянуть под капот и понять, что же там, внутри. Что такое алиасинг, где он может быть полезен и какие реальные преимущества дает. Тема будет рассмотрена и со стороны программиста и со стороны разработчика компилятора. А по сему, вопрос «зачем?» будет центральным в повествовании.
Юрий Ефимочев, Компилируемые в реальном времени DSL для С++ Sergey Platonov
В последнее время в промышленной разработке ПО особую популярность обретают Domain-Specific Lanugages (DSL). Они драматически упрощают разработку и дают возможность “программировать” не только программистам, но и пользователям прикладных программ.
В своем докладе я расскажу об опыте использования DSL применительно к С++, причем упор будет сделан на производительность кода DSL, и его мгновенную “встраиваемость” в запущенную программу путем компиляции DSL-кода в нативный код с помощью инструментария LLVM.
Использование юнит-тестов для повышения качества разработкиvictor-yastrebov
В докладе рассмотрены подходы к созданию надежных юнит-тестов, которые просты в поддержке и модернизации, а также принципы создания кода пригодного для покрытия автотестами. Приведены два способа внедрения зависимости: с использованием конструктора тестируемого объекта, а также с использованием подхода "выделить и переопределить". Каждый из способов разобран на примере, демонстрирующем особенности его реализации и применения. Приведен ряд практических советов, нацеленных на создание надежных юнит-тестов. Использование на практике приведенных подходов и принципов позволяет упростить процесс поддержки и модификации существующего кода, а также дает уверенность в надежности работы добавляемого нового функционала. В конечном итоге это приводит к повышению качества разрабатываемого продукта.
В рамках данного выступления вас ждут:
* рассказ о полезных и интересных вещах из Boost
* новости с передовиц разработки Boost и о новинках ожидаемых в следующих версиях
* что из Boost готовится к переезду в новый стандарт С++
* как экспериментировать с Boost, имея под рукой только браузер
* что людям не нравится в Boost и как с этими людьми бороться (-:
Современный статический анализ кода: что умеет он, чего не умели линтерыcorehard_by
Статический анализ появился почти 40 лет назад. В своём докладе мы хотим показать, чему за это время научились статические анализаторы. Мы рассмотрим различные методики анализа, как они появлялись и какие ошибки можно найти с помощью них. Посмотрим на примеры ошибок, найденных PVS-Studio в Open Source проектах. Поговорим о том, чем статический анализатор отличается от "линтеров" и некоторых других инструментов, а также какие проблемы решает современный статический анализатор C++ кода, помимо собственно анализа кода.
Павел Беликов
@PVS-Studio, Тула, Россия
Григорий Демченко, Асинхронность и неблокирующая синхронизацияSergey Platonov
Практика показывает, что использование подхода, основанного на колбеках для асинхронного программирования обычно не является удобным и подвержено различным ошибкам. Для упрощения написания и поддержки сложных асинхронных программ можно использовать несколько иной подход: использовать сопрограммы для переключения контекста на время ожидания события. Такой подход позволяет реализовать интересные неблокирующие примитивы, включая неблокирующее сетевое взаимодействие, неблокирующие мьютексы, а также удобное переключение между различными пулами потоков для разнесения выполнения задач, которые требуют различные ресурсы.
ЛЕКЦИЯ 8. Многопоточное программирование без использования блокировок. Модель потребитель-производитель. Потокобезопасный стек. Проблема ABA. Указатели опасности.
Курс "Параллельные вычислительные технологии" (ПВТ), весна 2015
Сибирский государственный университет телекоммуникаций и информатики
Пазников Алексей Александрович
к.т.н., доцент кафедры вычислительных систем СибГУТИ
http://cpct.sibsutis.ru/~apaznikov
Догнать и перегнать boost::lexical_castRoman Orlov
Разбор нестандартной реализации преобразования целого числа в строку без использования циклов и рекурсивных вызовов времени исполнения - только рекурсия на этапе компиляции
ЛЕКЦИЯ 5. Шаблоны многопоточного программирования
Курс "Параллельные вычислительные технологии" (ПВТ), весна 2015
Сибирский государственный университет телекоммуникаций и информатики
Пазников Алексей Александрович
к.т.н., доцент кафедры вычислительных систем СибГУТИ
http://cpct.sibsutis.ru/~apaznikov
Intel IPP Samples for Windows - работа над ошибкамиTatyanazaxarova
Это моя очередная заметка о том, как PVS-Studio делает программы более надёжными. То есть где, и какие ошибки он обнаруживает. На этот раз под молоток попали примеры, демонстрирующие работу с библиотекой IPP 7.0 (Intel Performance Primitives Library).
Андрей Карпов, Приватные байки от разработчиков анализатора кодаSergey Platonov
Доклад о редких нестандартных расширениях языка С++, про которые никто не знает, но которые надо поддерживать в анализаторе кода.
О магии Visual C++ с файлом stdafx.h, когда проект компилируется, хотя не должен. О том как зародился viva64 (предшественник PVS-Studio) для поиска 64-битных проблем. Как и почему исчез анализ кода, который одно время существовал в компиляторе Intel C++.
Доклад Кулагина И.И., Пазникова А.А., Курносова М.Г. "Оптимизация информационных обменов в параллельных PGAS-программах" на 3-й Всероссийской научно-технической конференции «Суперкомпьютерные технологии» (СКТ-2014)
29 сентября – 4 октября 2014 г., с. Дивноморское
Слайды доклада на конференции C++ Corehard Winter 2017 (г.Минск).
Автор доклада давно и успешно использует Модель Акторов при разработке приложений на C++. В основном это был положительный опыт. Но есть некоторые неочевидные моменты, про которые было бы хорошо узнать заранее. О том, где использование Модели Акторов уместно, а где нет, на какие грабли довелось наступить, какие шишки были набиты, как можно упростить себе жизнь и пойдет речь в докладе.
Многие разработчики не представляют, как дорого обходятся ошибки в программах. Причем я имею в виду не падения ракет и прочие катастрофы, а обыкновенное прикладное программное обеспечение. Хочется показать всю важность нахождения ошибок на самых ранних этапах. Одним из способов выявить ошибку как можно раньше является статический анализ кода. Поговорим мы не только об этом, но и о различных приемах при написании кода, которые позволят избежать множество типовых ошибок.
В третьей главе рассматриваются базовые свойства акторов, описанные в PhD диссертации Gul Agha: каждый актор имеет адрес, большой почтовый ящик, куда доставляются сообщения, адресованные актору и поведение. В ответ на входящее сообщение актор может отправить конечный набор сообщений другим акторам и/или создать конечное число новых акторов и/или поменять свое поведение для обработки следующего сообщения.
В рамках данного курса будет разработана библиотека для разработки параллельных приложений на платформе .NET, построенная по модели акторов.
Исходные коды библиотеки будут выкладываться на GitHub: https://github.com/hwdtech/HWdTech.DS
Код библиотеки будет разработан с использованием следующих принципов, приемов и методик:
S.O.L.I.D. - принципы
Unit-tests
Mock
IoC контейнеры
Для удобства слушателей курса краткий обзор данных практик приведен в Главе 4.
ЛЕКЦИЯ 7. Многопоточное программирование без блокировок. Модель потребитель-производитель. Потокобезопасный стек: проблема ABA, указатели опасности, сборщики мусора, счётчик ссылок, применение модели памяти С++.
Курс "Параллельные вычислительные технологии" (ПВТ), осень 2014
Сибирский государственный университет телекоммуникаций и информатики
Пазников Алексей Александрович
к.т.н., доцент кафедры вычислительных систем СибГУТИ
http://cpct.sibsutis.ru/~apaznikov
Доклад вводит в рассмотрение универсальный адаптер, позволяющий обернуть любой класс с целью добавления новых свойств, отсутствующих в оригинальном классе. Получаемые классы могут иметь в точности такой же интерфейс, как и первоначальные, что позволяет прозрачно заменять их и оборачивать любое количество раз.
Это позволяет добавлять необходимые свойства объектам, не переписывая его с нуля. Предложенная обобщенная концепция будет последовательно введена и проиллюстрирована простыми, но интересными примерами.
Юрий Ефимочев, Компилируемые в реальном времени DSL для С++ Sergey Platonov
В последнее время в промышленной разработке ПО особую популярность обретают Domain-Specific Lanugages (DSL). Они драматически упрощают разработку и дают возможность “программировать” не только программистам, но и пользователям прикладных программ.
В своем докладе я расскажу об опыте использования DSL применительно к С++, причем упор будет сделан на производительность кода DSL, и его мгновенную “встраиваемость” в запущенную программу путем компиляции DSL-кода в нативный код с помощью инструментария LLVM.
Использование юнит-тестов для повышения качества разработкиvictor-yastrebov
В докладе рассмотрены подходы к созданию надежных юнит-тестов, которые просты в поддержке и модернизации, а также принципы создания кода пригодного для покрытия автотестами. Приведены два способа внедрения зависимости: с использованием конструктора тестируемого объекта, а также с использованием подхода "выделить и переопределить". Каждый из способов разобран на примере, демонстрирующем особенности его реализации и применения. Приведен ряд практических советов, нацеленных на создание надежных юнит-тестов. Использование на практике приведенных подходов и принципов позволяет упростить процесс поддержки и модификации существующего кода, а также дает уверенность в надежности работы добавляемого нового функционала. В конечном итоге это приводит к повышению качества разрабатываемого продукта.
В рамках данного выступления вас ждут:
* рассказ о полезных и интересных вещах из Boost
* новости с передовиц разработки Boost и о новинках ожидаемых в следующих версиях
* что из Boost готовится к переезду в новый стандарт С++
* как экспериментировать с Boost, имея под рукой только браузер
* что людям не нравится в Boost и как с этими людьми бороться (-:
Современный статический анализ кода: что умеет он, чего не умели линтерыcorehard_by
Статический анализ появился почти 40 лет назад. В своём докладе мы хотим показать, чему за это время научились статические анализаторы. Мы рассмотрим различные методики анализа, как они появлялись и какие ошибки можно найти с помощью них. Посмотрим на примеры ошибок, найденных PVS-Studio в Open Source проектах. Поговорим о том, чем статический анализатор отличается от "линтеров" и некоторых других инструментов, а также какие проблемы решает современный статический анализатор C++ кода, помимо собственно анализа кода.
Павел Беликов
@PVS-Studio, Тула, Россия
Григорий Демченко, Асинхронность и неблокирующая синхронизацияSergey Platonov
Практика показывает, что использование подхода, основанного на колбеках для асинхронного программирования обычно не является удобным и подвержено различным ошибкам. Для упрощения написания и поддержки сложных асинхронных программ можно использовать несколько иной подход: использовать сопрограммы для переключения контекста на время ожидания события. Такой подход позволяет реализовать интересные неблокирующие примитивы, включая неблокирующее сетевое взаимодействие, неблокирующие мьютексы, а также удобное переключение между различными пулами потоков для разнесения выполнения задач, которые требуют различные ресурсы.
ЛЕКЦИЯ 8. Многопоточное программирование без использования блокировок. Модель потребитель-производитель. Потокобезопасный стек. Проблема ABA. Указатели опасности.
Курс "Параллельные вычислительные технологии" (ПВТ), весна 2015
Сибирский государственный университет телекоммуникаций и информатики
Пазников Алексей Александрович
к.т.н., доцент кафедры вычислительных систем СибГУТИ
http://cpct.sibsutis.ru/~apaznikov
Догнать и перегнать boost::lexical_castRoman Orlov
Разбор нестандартной реализации преобразования целого числа в строку без использования циклов и рекурсивных вызовов времени исполнения - только рекурсия на этапе компиляции
ЛЕКЦИЯ 5. Шаблоны многопоточного программирования
Курс "Параллельные вычислительные технологии" (ПВТ), весна 2015
Сибирский государственный университет телекоммуникаций и информатики
Пазников Алексей Александрович
к.т.н., доцент кафедры вычислительных систем СибГУТИ
http://cpct.sibsutis.ru/~apaznikov
Intel IPP Samples for Windows - работа над ошибкамиTatyanazaxarova
Это моя очередная заметка о том, как PVS-Studio делает программы более надёжными. То есть где, и какие ошибки он обнаруживает. На этот раз под молоток попали примеры, демонстрирующие работу с библиотекой IPP 7.0 (Intel Performance Primitives Library).
Андрей Карпов, Приватные байки от разработчиков анализатора кодаSergey Platonov
Доклад о редких нестандартных расширениях языка С++, про которые никто не знает, но которые надо поддерживать в анализаторе кода.
О магии Visual C++ с файлом stdafx.h, когда проект компилируется, хотя не должен. О том как зародился viva64 (предшественник PVS-Studio) для поиска 64-битных проблем. Как и почему исчез анализ кода, который одно время существовал в компиляторе Intel C++.
Доклад Кулагина И.И., Пазникова А.А., Курносова М.Г. "Оптимизация информационных обменов в параллельных PGAS-программах" на 3-й Всероссийской научно-технической конференции «Суперкомпьютерные технологии» (СКТ-2014)
29 сентября – 4 октября 2014 г., с. Дивноморское
Слайды доклада на конференции C++ Corehard Winter 2017 (г.Минск).
Автор доклада давно и успешно использует Модель Акторов при разработке приложений на C++. В основном это был положительный опыт. Но есть некоторые неочевидные моменты, про которые было бы хорошо узнать заранее. О том, где использование Модели Акторов уместно, а где нет, на какие грабли довелось наступить, какие шишки были набиты, как можно упростить себе жизнь и пойдет речь в докладе.
Многие разработчики не представляют, как дорого обходятся ошибки в программах. Причем я имею в виду не падения ракет и прочие катастрофы, а обыкновенное прикладное программное обеспечение. Хочется показать всю важность нахождения ошибок на самых ранних этапах. Одним из способов выявить ошибку как можно раньше является статический анализ кода. Поговорим мы не только об этом, но и о различных приемах при написании кода, которые позволят избежать множество типовых ошибок.
В третьей главе рассматриваются базовые свойства акторов, описанные в PhD диссертации Gul Agha: каждый актор имеет адрес, большой почтовый ящик, куда доставляются сообщения, адресованные актору и поведение. В ответ на входящее сообщение актор может отправить конечный набор сообщений другим акторам и/или создать конечное число новых акторов и/или поменять свое поведение для обработки следующего сообщения.
В рамках данного курса будет разработана библиотека для разработки параллельных приложений на платформе .NET, построенная по модели акторов.
Исходные коды библиотеки будут выкладываться на GitHub: https://github.com/hwdtech/HWdTech.DS
Код библиотеки будет разработан с использованием следующих принципов, приемов и методик:
S.O.L.I.D. - принципы
Unit-tests
Mock
IoC контейнеры
Для удобства слушателей курса краткий обзор данных практик приведен в Главе 4.
ЛЕКЦИЯ 7. Многопоточное программирование без блокировок. Модель потребитель-производитель. Потокобезопасный стек: проблема ABA, указатели опасности, сборщики мусора, счётчик ссылок, применение модели памяти С++.
Курс "Параллельные вычислительные технологии" (ПВТ), осень 2014
Сибирский государственный университет телекоммуникаций и информатики
Пазников Алексей Александрович
к.т.н., доцент кафедры вычислительных систем СибГУТИ
http://cpct.sibsutis.ru/~apaznikov
Доклад вводит в рассмотрение универсальный адаптер, позволяющий обернуть любой класс с целью добавления новых свойств, отсутствующих в оригинальном классе. Получаемые классы могут иметь в точности такой же интерфейс, как и первоначальные, что позволяет прозрачно заменять их и оборачивать любое количество раз.
Это позволяет добавлять необходимые свойства объектам, не переписывая его с нуля. Предложенная обобщенная концепция будет последовательно введена и проиллюстрирована простыми, но интересными примерами.
В своих прошлых докладах (http://cpp-russia.ru/?p=198, и http://cpp-russia.ru/?page_id=1239) я рассказывал о C++ без исключений, как с эти жить, как работать. Этот доклад является продолжением этой серии. Я рекомендую освежить в памяти предыдущие доклады, чтобы наша работа была более продуктивной. Мы обсудим механизмы создания, копирования и перемещения объектов, механизмы аллокации и деаллокации памяти, а также обработку ошибок и исключений. Также мы обсудим проблемы и неудобства, которые испытывает программист, когда пишет код без исключений. В конце, я попытаюсь показать, как можно проектировать структуры данных, контейнеры для удобной работы в средах с исключениями и без исключений.
Evgeniy Muralev, Mark Vince, Working with the compiler, not against itSergey Platonov
The talk will look at limitations of compilers when creating fast code and how to make more effective use of both the underlying micro-architecture of modern CPU's and how algorithmic optimizations may have surprising effects on the generated code. We shall discuss several specific CPU architecture features and their pros and cons in relation to creating fast C++ code. We then expand with several algorithmic techniques, not usually well-documented, for making faster, compiler friendly, C++.
Note that we shall not discuss caching and related issues here as they are well documented elsewhere.
Фитнес для вашего кода: как держать его в формеIlia Shishkov
C++ Россия 2017
Во время моего выступления мы поговорим о принципе "Minimize coupling, maximize cohesion". Обсудим, что это такое и что значат эти непонятные слова. Кроме того на приближенном к реальности примере мы рассмотрим, как, применяя указанный принцип, можно держать ваш код в форме, чтобы он был готов ко всем неожиданностям, которые подстерегают ваш проект в течение его жизни.
На протяжении всего существования C++ тема компайл-тайм рефлексии поднимается постоянно, но, к сожалению, до сих пор Стандарт языка не дает достаточных возможностей для извлечения и манипулирования компайл-тайм информацией. Большое количество библиотек и препроцессоров было придумано для того, чтобы решить эту проблему, начиная от простых макросов и заканчивая Qt-moc или ODB. В докладе Антон расскажет о том, как на эту проблему смотрит Комитет по Стандартизации: какие решения были предложены, и какое стало доминирующим.
Fuzzing is a software testing technique that involves providing invalid, unexpected, or random data to the inputs of a computer program. The presentation covers types of fuzzers and describes how they work. We will write and run a real fuzzer. Also it shows how fuzzers can guess correct CRC checksums, help with regression testing and find logical bugs in programs. Finally, it summarizes fuzzing usage at Google.
Василий Сорокин, Простой REST сервер на Qt с рефлексиейSergey Platonov
Библиотека Qt имеет довольно мощную систему рефлексии. На примере простого в использовании класса, позволяющего с помощью наследования быстро построить REST сервер под ваши нужды, я покажу как элегантно ее можно задействовать в реальной жизни. В заключительной части, покажу еще один пример когда рефлексия Qt помогает красиво протестировать испускание сигналов классом.
Хочется чего-то новенького, необычного? Тогда добро пожаловать в мир чудеc C++17:
if constexpr (auto& [number, ok] = variable; ok)
return "Hi"
else
return number + 42;
Вы услышите о новом стандарте C++, обнаружите для себя новые полезные классы, функции и возможности языка. Для каждой новинки я приведу примеры использования, расскажу о нюансах и подводных камнях.
А ещё вы узнаете о том, как проходят заседания комитета по стандартизации C++ и сможете задать интересующие вас вопросы связанные с нововведениями С++17 и С++Next.
Gor Nishanov, C++ Coroutines – a negative overhead abstractionSergey Platonov
C++ coroutines are one of the few major features that may land in C++17. We will look at the current standardization status, available experimental implementations and develop a small coroutine adapter over raw C networking APIs that will beat hand-crafted state machine in performance.
Повседневный С++: алгоритмы и итераторы corehard_by
Я рассмотрю ряд простых прикладных задач и покажу, как их можно эффективно и элегантно решить с помощью стандартных средств современного С++. Доклад включает работу с залом: участники будут предлагать свои улучшения для конкретных примеров кода, а также отвечать на поставленные вопросы (например, найти ошибку в приведённом примере). Доклад рассчитан на базовые знания языка.
Михаил Матросов
Технический менеджер @Align Technology, Москва
Actor model which is currently trending in software development is a popular design approach when it comes to complex applications. Many systems written in Erlang (Akka framework) are designed with actor model in their core. But Erlang and Akka are managed environments and safe programming languages. Is it worth using actor model in C++? If yes, where to look and what to use? The talk will cover all these topics.
шишки, набитые за 15 лет использования акторов в c++ v.001.3corehard_by
Автор доклада давно и успешно использует Модель Акторов при разработке приложений на C++. В основном это был положительный опыт. Но есть некоторые неочевидные моменты, про которые было бы хорошо узнать заранее. О том, где использование Модели Акторов уместно, а где нет, на какие грабли довелось наступить, какие шишки были набиты, как можно упростить себе жизнь и пойдет речь в докладе.
Евгений Охотников
Системный архитектор @stiffstream
Подробнее...
Actors for fun and profit, Евгений Охотников
На предыдущих конференциях C++ CoreHard автор уже рассказывал о Модели Акторов вообще и ее применимости в C++ в частности, а так же об уроках, которые довелось выучить за 15 лет использования Модели Акторов в C++. В этот раз речь зайдет о том, как же определить, стоит ли использовать Модель Акторов для решения конкретной задачи. И если стоит, то как это можно сделать. С поправкой на то, что C++ -- это небезопасный язык и приемы из намного более безопасных Erlang и Akka в C++ не очень-то и работают.
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Микросервисы, кто-то только слышал о них, кто-то пытался делать, кто-то уже использует в продакшене. Идеи, заложенные в концепцию микросервисов, не новы и основные постулаты уже звучали раньше. Так почему же в последнее время мы всё чаще слышим о микросервисах? Что такое микросервисы для нас и чем они отличаются от старого доброго подхода SOA? Как теперь разрабатывать enterprise-приложения с микросервисным подходом на нашем любимом языке программирования Java?
На эти и некоторые другие вопросы постараемся ответить во время встречи. Наши гости, Кирилл Толкачёв и Александр Тарасов, в режиме live coding попытаются создать небольшой стартап, попутно использовав новомодные подходы и инструменты.
На пути к релизу стартапа будут затронуты основные проблемы выбранных подходов в целом и технологий в частности:
Микросервис — что это, для чего и как с этим дальше жить. Где теория брат? ;)
На чём писать API: REST или RPC, и почему Thrift имеет право на жизнь в эпоху тотального распространения JSON-а. Упрощай и превозмогай с помощью Spring boot starter;
Какой стек выбрать для разработки, что выбрали мы и почему. Небольшое сравнение легковесных и не очень java фреймворков а так же сопутствующих инструментов;
Способы упаковки, дистрибуции и разворачивания микросервисов, как Spring Boot и Docker помогают нам в решении этих непростых для разработчика проблемах;
Как микросервисам найти друг друга, как готовить Spring Cloud и как обойти существующие проблемы и ограничения. Не доверяйте технологиям, доверяйте только себе;
API Gateway. Предохраняй и сохраняй свои микросервисы.
Так же речь пойдет о других распространенных проблемах распределенных систем и их решениях.
Статья представляет собой отчет о проверки библиотеки Loki на совместимость с 64-битными системами с помощью анализатора кода Viva64 компании ООО "СиПроВер". Содержатся рекомендации пользователям библиотеки. Статья будет полезна также пользователям других библиотек, построенных на шаблонах, так как раскрывает особенности анализа подобных библиотек.
arataga. SObjectizer and RESTinio in action: a real-world exampleYauheni Akhotnikau
Slides about the usage of SObjectizer and RESTinio in implementation of performant socks5/http1.1 proxy server that has to deal with thousands of entry points.
Actor Model and C++: what, why and how? (March 2020 Edition)Yauheni Akhotnikau
This is an updated version of slides from my talk on the C++ CoreHard Autumn 2016 conference.
The Actor Model which is currently trending in software development is a popular design approach when it comes to complex applications. Many systems are written in Erlang (Akka framework) are designed with the Actor Model in their core. But Erlang and Akka are managed environments and safe programming languages. Is it worth using the Actor Model in C++? If yes, where to look and what to use? The talk will cover all these topics.
Слайды одноименного доклада с конференции C++ CoreHard Autumn 2018 (г.Минск, 2018.11.03).
Краткое описание доклада:
На предыдущих конференциях C++ CoreHard автор доклада рассказывал про Модель Акторов и опыт ее использования в C++. Но Модель Акторов -- это далеко не единственный способ борьбы со сложностью при работе с многопоточностью. Давайте попробуем поговорить о том, что еще можно применить и как это может выглядеть в C++.
Shrimp: A Rather Practical Example Of Application Development With RESTinio a...Yauheni Akhotnikau
Description of a demo project for serving images by using Actor Model and embedded HTTP-server. This project is implemented in C++17 with SObjectizer and RESTinio (OpenSource products from stiffstream).
Акторы в C++: взгляд старого практикующего актородела (St. Petersburg C++ Use...Yauheni Akhotnikau
Автор доклада более 16 лет отвечает за развитие Open-Source фреймворка SObjectizer -- одного из немногих живых, эволюционирующих, кросс-платформенных фреймворков для C++, базирующихся на Модели Акторов. При этом SObjectizer никогда не был исследовательским экспериментом и с самого начала использовался в ряде business-critical проектов.
За годы разработки и эксплуатации SObjectizer накопился некоторый практический опыт использования акторов в С++, которым докладчик поделится со слушателями. Речь пойдет о том, почему Модель Акторов выглядит привлекательной, где и когда ее выгодно использовать. Какие особенности накладывает именно С++ и разумно ли использовать Модель Акторов в C++? Почему реализации Модели Акторов для C++ настолько разные и почему SObjectizer получился именно таким?
Слайды одноименного доклада с конференции "C++ Russia 2018". В докладе речь идет о том, насколько C++ мешает и насколько C++ помогает в разработке акторного фреймворка для C++.
GECon 2017: C++ - a Monster that no one likes but that will outlast them allYauheni Akhotnikau
Slides from my presentation from GECon-2017 conference: https://events.epam.com/events/gecon-2017
It covers the following topics:
A bit of C++ evolution history.
Why C++ became popular and why C++ started to lose its popularity.
Why C++ is a Monster? If C ++ is a monster, then why does someone need C++?
How to use C++ safely and efficiently?
Where and when C++ can be used. If it can...
Pressure to C++ from competitors. Real and imaginary.
Dive into SObjectizer 5.5. Tenth part: Mutable MessagesYauheni Akhotnikau
This part describes a feature which was introduced in v.5.5.19: an ability to send mutable messages with guarantees that it will be delivered to at most one receiver.
Dive into SObjectizer 5.5. Seventh part: Message LimitsYauheni Akhotnikau
Next part of serie with deep dive into SObjectizer-5.5. A brief explanation of message limits feature. This feature allows to protect agents from overloading in simple situations and can be used as building blocks for more complex and domain-specific overload control schemes.
3. Давным-давно, в далекой-далекой...
1994-й год.
Гомель.
КБ Системного Программирования.
Отдел АСУТП.
Попытка сделать объектно-ориентированную SCADA-систему.
SCADA - Supervisory Control And Data Acquisition
3
5. Объектная SCADA. Зачем?
Традиционный подход SCADA-систем в те времена:
● набор нумерованных или именованных каналов ввода-вывода (тегов);
● слабая структуризация и почти отсутствие декомпозиции;
● трудозатраты растут с увеличением числа тегов;
● трудозатраты еще быстрее растут по мере усложнения логики
автоматизируемого техпроцесса.
Мы хотели устранить это за счет декомпозиции на объекты,
обладающие состоянием и поведением.
5
6. Объектная SCADA. Что получилось?
Агенты:
● конечные автоматы с явно выделенными состояниями;
● состояния агентов видны снаружи.
6
7. Объектная SCADA. Что получилось?
Взаимодействие через асинхронные сообщения:
● прицел на soft real-time;
● распространение информации как в режиме 1:1, так и в
режиме 1:N.
7
8. Объектная SCADA. Что получилось?
Диспетчер.
Отвечал за обработку очередей сообщений с учетом приоритетов
и требований soft real-time.
8
9. Объектная SCADA. Итог
SCADA Objectizer.
1998-й год.
Опробован в реальном проекте.
Прекратил свое существование в начале 2000-го :(
9
10. Предпосылки к перерождению
Начало 2002-го.
Компания "Интервэйл".
Двое участников разработки SCADA Objectizer.
Небольшая GUI-программа для управления подключенными к ПК
устройствами...
10
12. Этапы большого пути
Май 2002-го: начало использования SO-4 в разработке.
Март 2006-го: перевод SO-4 в категорию OpenSource проектов
под BSD-лицензией.
Сентябрь 2010-го: начало работ над SObjectizer-5.
Май 2013-го: публичный релиз SO-5 под BSD-лицензией.
Июль 2013-го: SObjectizer начал жить независимо от "Интервэйл".
12
13. На данный момент...
Последняя стабильная версия SObjectizer-5.5.18 – это:
● 25KLOC кода (+28KLOC кода в тестах +10KLOC кода в
примерах);
● работа на платформах Windows, Linux, FreeBSD, MacOS, Android
(через CrystaX NDK);
● поддержка компиляторов VC++ 12.0-14.0, GCC 4.8-6.3, clang
3.5-3.9;
● документация, презентации, статьи;
● отсутствие больших ломающих изменений с октября 2014-го.
13
15. Как перестать бояться и...
...полюбить многопоточность?
Голые thread, mutex и condition_variable – это пот, кровь и боль.
Асинхронный обмен сообщениями рулит!
И бибикает :)
Ибо shared nothing и вот этот вот все.
15
16. Бонусы асинхронного обмена сообщениями
● у каждого агента свое изолированное состояние (принцип
shared nothing), упрощает жизнь в многопоточном коде;
● обмен сообщениями – естественный подход к решению
некоторых типов задач;
● слабая связность между компонентами;
● очень простая работа с таймерами (отложенные и
периодические сообщения);
● низкий порог входа для новичков.
16
18. В SObjectizer есть сообщения
Все взаимодействие между агентами в SObjectizer идет только
через асинхронные сообщения.
Сообщения это объекты. Тип сообщения наследуется от
so_5::message_t.
18
20. Отсылаются сообщения вот так:
// Безотлагательная отсылка сообщения.
so_5::send<request>(target,
// Все это через perfect-forwarding идет в конструктор request-а.
make_id(), make_params(), make_payload(), calculate_deadline());
// Безотлагательная отсылка сигнала.
so_5::send<get_status>(target);
// Отсылка сигнала с задержкой на 250ms.
so_5::send_delayed<get_status>(target, std::chrono::milliseconds(250));
// Периодическая отсылка сигнала со стартовой задержкой в 250ms
// и периодом повтора в 750ms.
auto timer = so_5::send_periodic<get_status>(target,
std::chrono::milliseconds(250),
std::chrono::milliseconds(750));
20
21. Что такое Target для send?
В "традиционной" Модели Акторов адресатом сообщения
является актор.
В SObjectizer сообщения отсылаются в "почтовый ящик".
Почтовый ящик в SObjectizer называется mbox.
21
22. Подписка на сообщение из mbox-а
Для получения сообщения из mbox-а нужно выполнить подписку.
Только после этого сообщения будут доставляться агенту.
Подписку можно отменить. Сообщения доставляться перестанут.
Подписки агента автоматически удаляются, когда агент
уничтожается.
Сообщения диспетчируются по типу, а не по содержимому.
22
24. Multi-Producer/Single-Consumer Mbox
Кто угодно может оправить. Подписаться может только один
агент.
MPSC-mbox создается для каждого агента автоматически.
Использование MPSC-mbox-ов дает максимально близкое
приближение к Модели Акторов.
24
25. Multi-Producer/Multi-Consumer Mbox
Кто угодно может оправить. Получат все подписчики.
MPMC-mbox нужно создавать вручную (можно с именем, можно
без).
Простейший вариант модели Publish/Subscribe.
25
26. В SObjectizer есть диспетчеры
Именно диспетчер определяет где и когда агент будет
обрабатывать свои сообщения.
Каждый агент в SObjectizer должен быть привязан к конкретному
диспетчеру.
В приложении может быть запущено сразу несколько
диспетчеров.
26
27. Примеры диспетчеров
one_thread: все агенты на одной и той же нити, все агенты используют
одну очередь сообщений.
active_obj: у каждого агента своя собственная нить, у каждого агента
собственная очередь сообщений.
adv_thread_pool: агенты на группе нитей, агент может мигрировать с
одной нити на другую, события одного агента могут быть запущены
параллельно, если они отмечены как thread_safe. Очереди сообщений
могут быть персональными или общими для нескольких агентов.
27
28. Больше диспетчеров, хороших и разных
Всего в SObjectizer-5 "из коробки" доступно восемь типов
диспетчеров:
active_group
active_obj
adv_thread_pool
one_thread
prio_dedicated_threads::one_per_prio
prio_one_thread::quoted_round_robin
prio_one_thread::strictly_ordered
thread_pool
28
30. В SObjectizer есть агенты
Как правило, реализуются как объекты классов, унаследованных
от so_5::agent_t.
class hello_world final : public so_5::agent_t {
public :
using so_5::agent_t::agent_t;
virtual void so_evt_start() override {
std::cout << "Hello, World!" << std::endl;
so_deregister_agent_coop_normally();
}
};
30
31. Агенты – это конечные автоматы
1. Мы не поддерживаем агентов в виде сопрограмм. Поэтому
должен использоваться механизм callback-ов, чтобы
отобразить N агентов на M рабочих нитей.
2. Ноги у SObjectizer растут из мира АСУТП, там конечные
автоматы – это обычное дело.
3. Когда есть ярко выраженные состояния и разное поведение в
каждом из состояний конечный автомат удобнее, чем вызовы
receive с последующим выбором обработчика.
31
33. Агент blinking_led (код)
class blinking_led final : public so_5::agent_t {
state_t off{ this }, blinking{ this },
blink_on{ initial_substate_of{ blinking } },
blink_off{ substate_of{ blinking } };
public :
struct turn_on_off : public so_5::signal_t {};
blinking_led( context_t ctx ) : so_5::agent_t{ std::move(ctx) } {
this >>= off;
off.just_switch_to< turn_on_off >( blinking );
blinking.just_switch_to< turn_on_off >( off );
blink_on
.on_enter( []{ std::cout << "ON" << std::endl; } )
.on_exit( []{ std::cout << "off" << std::endl; } )
.time_limit( std::chrono::milliseconds{1500}, blink_off );
blink_off
.time_limit( std::chrono::milliseconds{750}, blink_on );
}
};
33
34. Агент blinking_led (пояснения)
class blinking_led final : public so_5::agent_t {
state_t off{ this }, blinking{ this },
blink_on{ initial_substate_of{ blinking } },
blink_off{ substate_of{ blinking } };
public :
struct turn_on_off : public so_5::signal_t {};
blinking_led( context_t ctx ) : so_5::agent_t{ std::move(ctx) } {
this >>= off;
off.just_switch_to< turn_on_off >( blinking );
blinking.just_switch_to< turn_on_off >( off );
blink_on
.on_enter( []{ std::cout << "ON" << std::endl; } )
.on_exit( []{ std::cout << "off" << std::endl; } )
.time_limit( std::chrono::milliseconds{1500}, blink_off );
blink_off
.time_limit( std::chrono::milliseconds{750}, blink_on );
}
};
34
Определение двух
верхнеуровневых
состояний.
35. Агент blinking_led (пояснения)
class blinking_led final : public so_5::agent_t {
state_t off{ this }, blinking{ this },
blink_on{ initial_substate_of{ blinking } },
blink_off{ substate_of{ blinking } };
public :
struct turn_on_off : public so_5::signal_t {};
blinking_led( context_t ctx ) : so_5::agent_t{ std::move(ctx) } {
this >>= off;
off.just_switch_to< turn_on_off >( blinking );
blinking.just_switch_to< turn_on_off >( off );
blink_on
.on_enter( []{ std::cout << "ON" << std::endl; } )
.on_exit( []{ std::cout << "off" << std::endl; } )
.time_limit( std::chrono::milliseconds{1500}, blink_off );
blink_off
.time_limit( std::chrono::milliseconds{750}, blink_on );
}
};
35
Определение двух вложенных
состояний для состояния blinking.
Подсостояние blink_on является
начальным подсостоянием.
36. Агент blinking_led (пояснения)
class blinking_led final : public so_5::agent_t {
state_t off{ this }, blinking{ this },
blink_on{ initial_substate_of{ blinking } },
blink_off{ substate_of{ blinking } };
public :
struct turn_on_off : public so_5::signal_t {};
blinking_led( context_t ctx ) : so_5::agent_t{ std::move(ctx) } {
this >>= off;
off.just_switch_to< turn_on_off >( blinking );
blinking.just_switch_to< turn_on_off >( off );
blink_on
.on_enter( []{ std::cout << "ON" << std::endl; } )
.on_exit( []{ std::cout << "off" << std::endl; } )
.time_limit( std::chrono::milliseconds{1500}, blink_off );
blink_off
.time_limit( std::chrono::milliseconds{750}, blink_on );
}
};
36
Перевод агента в то состояние, в
котором он должен начать свою работу.
Кому не нравится перегрузка >>= для смены состояния
агента, для тех есть альтернативный синтаксис:
off.activate();
so_change_state(off);
37. Агент blinking_led (пояснения)
class blinking_led final : public so_5::agent_t {
state_t off{ this }, blinking{ this },
blink_on{ initial_substate_of{ blinking } },
blink_off{ substate_of{ blinking } };
public :
struct turn_on_off : public so_5::signal_t {};
blinking_led( context_t ctx ) : so_5::agent_t{ std::move(ctx) } {
this >>= off;
off.just_switch_to< turn_on_off >( blinking );
blinking.just_switch_to< turn_on_off >( off );
blink_on
.on_enter( []{ std::cout << "ON" << std::endl; } )
.on_exit( []{ std::cout << "off" << std::endl; } )
.time_limit( std::chrono::milliseconds{1500}, blink_off );
blink_off
.time_limit( std::chrono::milliseconds{750}, blink_on );
}
};
37
Реакция на сигнал включения и
выключения для верхних состояний.
Достаточно просто перейти в другое
состояние.
38. Агент blinking_led (пояснения)
class blinking_led final : public so_5::agent_t {
state_t off{ this }, blinking{ this },
blink_on{ initial_substate_of{ blinking } },
blink_off{ substate_of{ blinking } };
public :
struct turn_on_off : public so_5::signal_t {};
blinking_led( context_t ctx ) : so_5::agent_t{ std::move(ctx) } {
this >>= off;
off.just_switch_to< turn_on_off >( blinking );
blinking.just_switch_to< turn_on_off >( off );
blink_on
.on_enter( []{ std::cout << "ON" << std::endl; } )
.on_exit( []{ std::cout << "off" << std::endl; } )
.time_limit( std::chrono::milliseconds{1500}, blink_off );
blink_off
.time_limit( std::chrono::milliseconds{750}, blink_on );
}
};
38
Реакция на вход и
выход из состояния.
39. Агент blinking_led (пояснения)
class blinking_led final : public so_5::agent_t {
state_t off{ this }, blinking{ this },
blink_on{ initial_substate_of{ blinking } },
blink_off{ substate_of{ blinking } };
public :
struct turn_on_off : public so_5::signal_t {};
blinking_led( context_t ctx ) : so_5::agent_t{ std::move(ctx) } {
this >>= off;
off.just_switch_to< turn_on_off >( blinking );
blinking.just_switch_to< turn_on_off >( off );
blink_on
.on_enter( []{ std::cout << "ON" << std::endl; } )
.on_exit( []{ std::cout << "off" << std::endl; } )
.time_limit( std::chrono::milliseconds{1500}, blink_off );
blink_off
.time_limit( std::chrono::milliseconds{750}, blink_on );
}
};
39
time_limit задает ограничение на
время пребывания агента в
состоянии.
По истечении этого времени агент
автоматически меняет состояние.
40. Еще один пример: request_processor (код)
class request_processor : public so_5::agent_t {
state_t st_waiting{ this }, st_working{ this }, ...;
const so_5::mbox_t src_;
public :
request_processor(context_t ctx, so_5::mbox_t src) : so_5::agent_t(std::move(ctx)), src_(std::move(src)) {}
virtual void so_define_agent() override {
this >>= st_waiting;
st_waiting
.event(src_, &request_processor::on_request)
.event(src_, &request_processor::on_status_when_waiting);
st_working
.event(src_, &request_processor::on_request)
.event(src_, &request_processor::on_status_when_working);
...
}
...
private :
void on_request(const request & cmd) {...}
void on_status_when_waiting(mhood_t<get_status>) {...}
void on_status_when_working(mhood_t<get_status>) {...}
};
40
41. Еще один пример: request_processor (пояснения)
class request_processor : public so_5::agent_t {
state_t st_waiting{ this }, st_working{ this }, ...;
const so_5::mbox_t src_;
public :
request_processor(context_t ctx, so_5::mbox_t src) : so_5::agent_t(std::move(ctx)), src_(std::move(src)) {}
virtual void so_define_agent() override {
this >>= st_waiting;
st_waiting
.event(src_, &request_processor::on_request)
.event(src_, &request_processor::on_status_when_waiting);
st_working
.event(src_, &request_processor::on_request)
.event(src_, &request_processor::on_status_when_working);
...
}
...
private :
void on_request(const request & cmd) {...}
void on_status_when_waiting(mhood_t<get_status>) {...}
void on_status_when_working(mhood_t<get_status>) {...}
};
41
Почтовый ящик, из которого агент ожидает
запросы. Создается кем-то и отдается
агенту в качестве параметра конструктора.
42. Еще один пример: request_processor (пояснения)
class request_processor : public so_5::agent_t {
state_t st_waiting{ this }, st_working{ this }, ...;
const so_5::mbox_t src_;
public :
request_processor(context_t ctx, so_5::mbox_t src) : so_5::agent_t(std::move(ctx)), src_(std::move(src)) {}
virtual void so_define_agent() override {
this >>= st_waiting;
st_waiting
.event(src_, &request_processor::on_request)
.event(src_, &request_processor::on_status_when_waiting);
st_working
.event(src_, &request_processor::on_request)
.event(src_, &request_processor::on_status_when_working);
...
}
...
private :
void on_request(const request & cmd) {...}
void on_status_when_waiting(mhood_t<get_status>) {...}
void on_status_when_working(mhood_t<get_status>) {...}
};
42
Метод so_define_agent() дает
возможность агенту произвести
"настройку" перед тем, как начать
работать внутри SObjectizer.
Обычно используется для создания
подписок.
43. Еще один пример: request_processor (пояснения)
class request_processor : public so_5::agent_t {
state_t st_waiting{ this }, st_working{ this }, ...;
const so_5::mbox_t src_;
public :
request_processor(context_t ctx, so_5::mbox_t src) : so_5::agent_t(std::move(ctx)), src_(std::move(src)) {}
virtual void so_define_agent() override {
this >>= st_waiting;
st_waiting
.event(src_, &request_processor::on_request)
.event(src_, &request_processor::on_status_when_waiting);
st_working
.event(src_, &request_processor::on_request)
.event(src_, &request_processor::on_status_when_working);
...
}
...
private :
void on_request(const request & cmd) {...}
void on_status_when_waiting(mhood_t<get_status>) {...}
void on_status_when_working(mhood_t<get_status>) {...}
};
43
Подписка на сообщения.
Явным образом задается mbox из которого ожидаются
сообщения.
Тип сообщения не указан явно, он выводится
автоматически из типа аргумента обработчика.
44. Еще один пример: request_processor (пояснения)
class request_processor : public so_5::agent_t {
state_t st_waiting{ this }, st_working{ this }, ...;
const so_5::mbox_t src_;
public :
request_processor(context_t ctx, so_5::mbox_t src) : so_5::agent_t(std::move(ctx)), src_(std::move(src)) {}
virtual void so_define_agent() override {
this >>= st_waiting;
st_waiting
.event(src_, &request_processor::on_request)
.event(src_, &request_processor::on_status_when_waiting);
st_working
.event(src_, &request_processor::on_request)
.event(src_, &request_processor::on_status_when_working);
...
}
...
private :
void on_request(const request & cmd) {...}
void on_status_when_waiting(mhood_t<get_status>) {...}
void on_status_when_working(mhood_t<get_status>) {...}
};
44
Обработчик для сообщений с типом request.
Такой формат обработчика требует, чтобы
request был сообщением, а не сигналом.
45. Еще один пример: request_processor (пояснения)
class request_processor : public so_5::agent_t {
state_t st_waiting{ this }, st_working{ this }, ...;
const so_5::mbox_t src_;
public :
request_processor(context_t ctx, so_5::mbox_t src) : so_5::agent_t(std::move(ctx)), src_(std::move(src)) {}
virtual void so_define_agent() override {
this >>= st_waiting;
st_waiting
.event(src_, &request_processor::on_request)
.event(src_, &request_processor::on_status_when_waiting);
st_working
.event(src_, &request_processor::on_request)
.event(src_, &request_processor::on_status_when_working);
...
}
...
private :
void on_request(const request & cmd) {...}
void on_status_when_waiting(mhood_t<get_status>) {...}
void on_status_when_working(mhood_t<get_status>) {...}
};
45
Обработчики для сообщений или сигналов
с типом get_status.
Такой формат обработчика позволяет
обрабатывать и сообщения, и сигналы. Что
удобно при написании обобщенного кода в
агентах.
49. Наполнение и регистрация коопераций
so_5::environment_t & env = ...; // Доступ к SObjectizer.
// Заставляем SObjectizer создать объект кооперации.
auto coop = env.create_coop( "data_acquire_demo" );
// Наполняем кооперацию прикладными агентами. Заодно привязываем агентов к разным диспетчерам для того,
// чтобы агенты работали на разных рабочих нитях.
coop->make_agent_with_binder<device_reader>(
so_5::disp::one_thread::create_private_disp(env, "device")->binder(),
... );
coop->make_agent<data_processor>(...);
coop->make_agent_with_binder<db_writer>(
so_5::disp::one_thread::create_private_disp(env, "db")->binder(), ... );
// Осталось только зарегистрировать кооперацию.
env.register_coop(std::move(coop));
49
(1)
50. Наполнение и регистрация коопераций
so_5::environment_t & env = ...; // Доступ к SObjectizer.
// Заставляем SObjectizer создать объект кооперации.
auto coop = env.create_coop( "data_acquire_demo" );
// Наполняем кооперацию прикладными агентами. Заодно привязываем агентов к разным диспетчерам для того,
// чтобы агенты работали на разных рабочих нитях.
coop->make_agent_with_binder<device_reader>(
so_5::disp::one_thread::create_private_disp(env, "device")->binder(),
... );
coop->make_agent<data_processor>(...);
coop->make_agent_with_binder<db_writer>(
so_5::disp::one_thread::create_private_disp(env, "db")->binder(), ... );
// Осталось только зарегистрировать кооперацию.
env.register_coop(std::move(coop));
50
(2)
51. Наполнение и регистрация коопераций
so_5::environment_t & env = ...; // Доступ к SObjectizer.
// Заставляем SObjectizer создать объект кооперации.
auto coop = env.create_coop( "data_acquire_demo" );
// Наполняем кооперацию прикладными агентами. Заодно привязываем агентов к разным диспетчерам для того,
// чтобы агенты работали на разных рабочих нитях.
coop->make_agent_with_binder<device_reader>(
so_5::disp::one_thread::create_private_disp(env, "device")->binder(),
... );
coop->make_agent<data_processor>(...);
coop->make_agent_with_binder<db_writer>(
so_5::disp::one_thread::create_private_disp(env, "db")->binder(), ... );
// Осталось только зарегистрировать кооперацию.
env.register_coop(std::move(coop));
51
(3)
52. Регистрация кооперации – это просто?
1. Проверка уникальности имени.
2. Проверка родительской кооперации (если есть).
3. Запрос ресурсов у диспетчеров.
4. Вызов so_define_agent() для каждого агента.
5. Окончательная привязка агентов к диспетчерам, инициация
so_evt_start().
52
53. По традиции: hello_world
#include <so_5/all.hpp>
class hello_world final : public so_5::agent_t {
public :
using so_5::agent_t::agent_t;
virtual void so_evt_start() override {
std::cout << "Hello, World!" << std::endl;
so_deregister_agent_coop_normally();
}
};
int main() {
so_5::launch([](so_5::environment_t & env) {
env.register_agent_as_coop("hello", env.make_agent<hello_world>());
});
return 0;
}
53
54. Распределенности в SObjectizer-5 нет
Распределенность "из коробки" была в SObjectizer-4. Но:
● для разных задач нужны разные протоколы (одно дело –
передача телеметрии, другое – передача больших BLOB-ов);
● back pressure в асинхронном обмене сообщении сам по себе
непрост. В случае IPC эта проблема усугубляется;
● интероперабельность с другими языками программирования.
Точнее, ее отсутствие.
Поэтому в SObjectizer-5 распределенности нет.
54
56. Реализация Модели Акторов не самоцель
У нас нет цели сделать из SObjectizer самую лучшую и/или самую
полноценную реализацию Модели Акторов.
Мы говорим "акторный фреймворк" только потому, что:
● так проще объяснять, что это в принципе такое;
● маркетинг.
56
60. Поэтому на самом-то деле...
It's all about in-process message
dispatching!
60
61. Наша же цель в том, чтобы...
...предоставить разработчику небольшой качественный и
стабильный инструмент.
Практичный и настраиваемый под нужды пользователя.
Стабильность и совместимость. За это мы готовы платить.
Например, поддержка Ubuntu 14.04 LTS и тамошнего gcc-4.8 для
нас важнее, чем возможность использовать C++14 в коде
SObjectizer.
61
63. В двух словах
Современный C++ для нас очень важен.
Даже так: если бы не C++11, SObjectizer-5 вряд ли появился бы.
Есть в C++11 вещи, без которых SObjectizer сейчас сложно
представить...
63
64. Variadic templates и perfect forwarding
Используются в SObjectizer повсеместно:
template<typename MSG, typename... ARGS>
void send(const mbox_t & to, ARGS &&... args)
{
auto m = make_unique<MSG>(std::forward<ARGS>(args)...);
to->deliver_message(std::move(m));
}
class agent_coop_t {
public :
...
template< class AGENT, typename... ARGS >
AGENT * make_agent( ARGS &&... args ) {
auto a = make_unique< AGENT >( environment(), std::forward<ARGS>(args)... );
return this->add_agent( std::move( a ) );
}
};
64
65. Лямбды (особенно в сочетании с шаблонами)
Ну очень сильно помогают. В том числе и для обеспечения
гарантий безопасности исключений...
void agent_core_t::next_coop_reg_step__update_registered_coop_map(
const coop_ref_t & coop_ref,
coop_t * parent_coop_ptr )
{
m_registered_coop[ coop_ref->query_coop_name() ] = coop_ref;
m_total_agent_count += coop_ref->query_agent_count();
so_5::details::do_with_rollback_on_exception(
[&] {
next_coop_reg_step__parent_child_relation( coop_ref, parent_coop_ptr );
},
[&] {
m_total_agent_count -= coop_ref->query_agent_count();
m_registered_coop.erase( coop_ref->query_coop_name() );
} );
}
65
(1)
(2)
(3)
66. auto и decltype
Сложно переоценить важность auto в современном C++.
Особенно для вывода типа результата функции.
template< typename MAIN_ACTION, typename ROLLBACK_ACTION >
auto do_with_rollback_on_exception(
MAIN_ACTION main_action,
ROLLBACK_ACTION rollback_action ) -> decltype(main_action())
{
using result_type = decltype(main_action());
using namespace rollback_on_exception_details;
rollbacker_t< ROLLBACK_ACTION > rollbacker{ rollback_action };
return executor< result_type, MAIN_ACTION, ROLLBACK_ACTION >::exec(
main_action, rollbacker );
}
66
67. Стандартная библиотека C++11
Появление thread, mutex, condition_variable, atomic, unordered_map
и пр. в стандартной библиотеке C++11 позволило нам избавиться
от такой зависимости, как ACE.
Стало гораздо легче.
Правда, пришлось делать свою реализацию таймеров, но это уже
совсем другая история...
67
68. Краткое резюме по современному C++
C++11/14 – это уже совсем другой C++.
Использовать современный C++ намного удобнее, особенно, если
есть возможность пользоваться C++14.
Инфраструктура вокруг языка продолжает желать много лучшего.
Но мы над этим работаем ;)
68
70. SObjectizer: https://sourceforge.net/p/sobjectizer или https://github.com/eao197/so-5-5
Документация по SObjectizer: https://sourceforge.net/p/sobjectizer/wiki/Home/
Серия статей о SObjectizer на русском:
SObjectizer: что это, для чего это и почему это выглядит именно так? От простого к сложному:
Часть I, Часть II, Часть III. Акторы в виде конечных автоматов – это плохо или хорошо?
Проблема перегрузки агентов и средства борьбы с ней. Нежная дружба агентов и
исключений.
Серия презентаций о SObjectizer на английском "Dive into SObjectizer-5.5":
Intro, Agent's States, More About Coops, Exceptions, Timers, Synchonous Interaction, Message
Limits, Dispatchers, Message Chains.
70