Несколько недель назад состоялась встреча международного комитета по стандартизации C++. На ней люди (в основном) не разменивались на мелочи и совершили несколько больших шагов на пути к С++20.
Главные новости:
Что всё это значит, как это упростит написание кода и что было ещё — читайте под катом.
Читать полностью »
Наслаждаясь созданием моделей в Питоне на замечательных Deep Learning фреймворках типа Keras или Lasagne, время от времени хочется посмотреть, а что там интересного появилось для C++ разработчиков, помимо мейнстримовых TensorFlow и Caffe. Я решил поближе посмотреть на трех представителей: tiny-dnn, Apache.SINGA и OpenNN. Краткое описание опыта установки, сборки и использования под Windows Вы и найдете под катом.
Корни SObjectizer берут свое начало в теме автоматизированных систем управления технологическими процессами (АСУТП). Но использовали мы SObjectizer в далеких от АСУТП областях. Поэтому иногда возникает ностальгия из категории «эх, давно не брал в руки шашек...» Однажды из-за этого в составе SObjectizer появился один из самых объемных примеров — machine_control. Уж очень тогда захотелось «тряхнуть стариной», смоделировать задачку управления оборудованием на современном SObjectizer-е. Ну и под шумок запихнуть в пример разные вкусные фичи SObjectizer-а вроде фильтров доставки, шаблонных агентов и диспетчера с поддержкой приоритетов. Сегодня попробуем рассказать и показать, как это все работает.
Photo by Mike Boening
Когда мы начали рассказывать про свой OpenSource акторный фреймворк для C++ на Хабре, мы пообещали описывать некоторые особенности деталей реализации SObjectizer-а. Одна из новых фич, которая была реализована в недавно вышедшей версии 5.5.19, отлично подходит для такого рассказа. Кроме того, она интересна еще и тем, что нам пришлось взглянуть на сценарии использования SObjectizer с совершенно другой стороны. Можно даже сказать, что один из наших шаблонов оказался разорванным.
Речь идет о возможности SObjectizer-а выполнять все свои действия на одной единственной рабочей нити. Начиная с версии 5.5.19 использовать Actor- и Publish/Subscribe модели можно даже в однопоточном приложении. Понятное дело, что акторы должны будут работать в режиме кооперативной многозадачности, но в каких-то случаях именно это и требуется.
Завершаем рассказ, начатый в первой части. Сегодня рассмотрим еще несколько граблей, на которые довелось наступить за годы использования SObjectizer-а в повседневной работе.
Акторы в Модели Акторов и агенты у нас в SObjectizer общаются посредством асинхронных сообщений. И в этом кроется одна из причин привлекательности Модели Акторов для некоторых типов задач. Казалось бы, асинхронность — это один из краеугольных камней, один из бонусов, поэтому пользуйся себе на здоровье и получай удовольствие.
Ан нет. На практике быстро начались просьбы сделать в SObjectizer возможность синхронного взаимодействия агентов. Очень долго я этим просьбам сопротивлялся. Но в конце-концов сдался. Пришлось добавить в SObjectizer возможность выполнить синхронный запрос от одного агента к другому.
Выглядит в коде это вот так:
Данная статья является первой частью текстовой версии одноименного доклада с февральской конференции C++ CoreHard Winter 2017. Так уж получилось, что вот уже 15 лет я отвечаю за разработку фреймворка SObjectizer. Это один из тех немногих все еще живых и все еще развивающихся OpenSource фреймворков для C++, которые позволяют использовать Модель Акторов. Соответственно, за это время неоднократно доводилось попробовать Модель Акторов в деле, в результате чего накопился некоторый опыт. В основном это был положительный опыт, но есть и некоторые неочевидные моменты, про которые было бы хорошо узнать заранее. О том, на какие грабли довелось наступить, какие шишки были набиты, как можно упростить себе жизнь и как это сказалось на развитии SObjectizer-а и пойдет речь далее.
Подозреваю, что многое из того, о чем я буду говорить, хорошо известно в Erlang-сообществе. Но Erlang-сообщество слабо пересекается с C++ сообществом. Кроме того, есть разница между тем, что доступно Erlang-разработчику и тем, что доступно C++ разработчику. Поэтому надеюсь, что данная статья окажется интересной и полезной C++никам.
В начале марта в американском городе Кона завершилась встреча международной рабочей группы WG21 по стандартизации C++ в которой участвовали сотрудники Яндекса.
Заседания, как обычно, занимали целый день плюс дополнительно заседала подгруппа по работе с числами.
Основное время было посвящено полировке черновика C++17, но несколько небольших и интересных нововведений все же успели проскочить в C++17.
Читать полностью »
Хотя и существуют уже библиотеки для юнит-тестирования кода на С++, например, Google Test или Bandit, но они написаны не мной здесь оно, на мой взгляд, как-то переусложнено, по сравнению с тем же JS. Там просто делаешь, например, npm i mocha assert --save-dev и можно приступать к написанию тестов, а здесь же нужно это сделать ручками, а в случае с gtest еще и собрать с помощью cmake ее. Bandit подключается просто, но не умеет в сериализацию результатов в какой-то формат данных, gtest это умеет, но его нужно собирать отдельно. А я не хочу выбирать "либо то, либо это". Мне было нужно сделать удобный и простой инструмент под мои задачи. Я хотел получить простую библиотеку без зависимостей, header-only, на несколько файлов, которую можно легко и быстро подключить к своему проекту, удобно внести в нее изменения (если это будет необходимо). Но, самое основное, мне хотелось получать удобные, машиночитаемые отчеты, причем не только в stdout (или xml, как в gtest), но и в любой другой формат, который я захочу. Далее под катом.
