[prog.c++] В предвкушении C++17...

Неделю проколупался со старым кодом в C++03, сегодня представилась возможность попрограммировать на C++14. Как глоток свежего воздуха. Причем не только из-за большей лаконичности и выразительности современного C++, но и из-за того, что в C++11/14 за счет move-semantic контролировать эффективность кода намного проще.

А ведь на подходе уже и C++17, со своими вкусностями. Предвкушая появление которых даже не хочется вспоминать, что в планах были еще и какие-то концепты. Хрен с ними, с концептами, они нужны-то паре-тройке разработчиков библиотек вроде Boost.Fusion или Boost.Hana ;) Шутка :)

А вот это вот:

struct A { int i, j; } f(); auto [ x, y ] = f(); // declares x and y to refer to the members of the f return value if (auto x = current_state(); x.ok()) { x.do_more_stuff(); } if (auto [ x, y ] = f(); x < 42) { /* use y */; }

Облегчит жизнь очень многих рядовых C++ разработчиков.

PS. Пост написан под впечатлением вот от этого: Red Hat at the ISO C++ Standards Meeting (June 2016, Oulu): Core Language. Там еще больше вкусностей упомянуто :)

[prog.actors] "Банан велик, а..." или в поисках подходящей темы

Первая статья про SObjectizer на Хабре, как мне представляется, зашла более-менее хорошо. Есть желание написать еще две-три статьи с продолжением. В одной было бы хорошо показать на примере, как модель акторов вообще (ну и SO-5 в частности), помогает решать конкретные проблемы. В следующей немного подробнее рассказать о подводных камнях программирования на акторах и об уроках, которые нам довелось выучить за время использования SObjectizer-а. Дальше можно было бы поговорить о деталях реализации и особенностях использования акторов в C++.

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

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

Посему обращаюсь с просьбой к читателям: если у вас есть подходящая тема или задачка, для которой вам было бы интересно увидеть решение на агентах, то опишитесь в комментариях или мне на почту eao197 на gmail тчк com. Может вы сами что-то навелосипедили и вам было бы интересно сравнить свой подход с нашим? Может вы что-то делали на других языках/технологиях и хотели бы сравнить к кодом на C++? В общем, буду признателен за любую интересную идею.

В качестве примера: интересная задачка от ув.тов.thedeemon, которая уже разбиралась в блоге.

Upd. В качестве возможной темы: организация стадийности обработки и механизм работы в стиле fire-and-forget (так же известный, как SEDA-way). Т.е. когда есть N агентов, каждый из которых отвечает за свою операцию, агент i получает сообщение, он выполняет свои действия и отсылает сообщение агенту (i+1), при этом агенты в цепочке могут работать на разных диспетчерах (тем самым обеспечивается и загрузка имеющихся мощностей, и независимость разных операций друг от друга).

---

По поводу фразы "Банан велик, а..." из заголовка. Была такая байка:

Как-то раз американский физик-экспериментатор Р. Вуд (1868—1955), довольно эксцентричный человек, любитель всяких острых ощущений, решил проделать на себе рискованный опыт — испытать действие наркотика. С большим трудом раздобыв опиум, он накурился этого зелья и вскоре впал в забытье. Придя через некоторое время в сознание, он вспомнил, что, находясь в одурманенном состоянии, напал на какую-то чрезвычайно глубокую и важную научную идею, но на какую именно — начисто вылетело из головы. Тогда Вуд решил повторить опыт в надежде, что ему посчастливится вновь обрести ускользнувшую мысль. И действительно, как только начало сказываться наркотическое действие опиума, забытая мысль не замедлила возникнуть в уме ученого. Чувствуя, что сознание вот-вот покинет его, Вуд сумел в последний момент сконцентрировать волю, записать идею на бумажке и впал в беспамятство. Очнувшись, он с ликованием подумал об удачном исходе столь трудного и опасного опыта и, дрожа от нетерпения и пережитого, поспешно развернул бумажку с драгоценной записью. На ней он прочел; “Банан велик, а кожура еще больше...”

Вот что-то похожее было вчера со мной: помню, что уже засыпая придумал хорошую тему для следующей статьи про SO-5. А сегодня с утра не могу ее вспомнить... И хотя есть ощущение, что тема была хорошей, велика вероятность, что на самом деле она была чем-то вроде "Банан велик, а кожура еще больше" :)

[prog.c++] SObjectizer 4.5 -- немного позанимался софтонекрофилией :)

SObjectizer-4 был написан в 2002-ом году. Затем более-менее активно развивался года до 2004-го. Потом менее активно, но все-таки куда-то двигался до 2006-го года, когда была сделана версия 4.4. После чего развитие линейки SObjectizer-4 остановилось окончательно. Были баг фиксы, последний из которых, если не ошибаюсь, был сделан где-то в середине 2010-го года. Но развития уже не было. Вот уже 10 лет как.

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

Тем удивительнее было обнаружить, что софт на SO-4 не только есть, но он еще и работает. И, время от времени, нуждается в доработках. Правда, используются для этого какие-то древние компиляторы, да и собираются приложения в 32-х битовом режиме, т.к. были в свое время какие-то заморочки с какими-то библиотеками из-за чего портировать SO-4 в 64-бита не стали.

Ну а т.к. негоже по нынешним временам сидеть на древних C++03 компиляторах, то на выходных портировал SObjectizer-4 и сопутствующие ему библиотеки под C++11/14. Или, другими словами, после многолетнего перерыва появилась версия SObjectizer 4.5. Чему я сам несказанно удивлен, т.к. не мог себе представить такого развития событий и в кошмарном сне :)

Тем не менее, если вдруг кому-то надо, то можно взять SO-4.5 из SVN-а. Проверял работоспособность под Windows и VC++ 14.0, под Linux и GCC-6.1 (но, думаю, и под 4.9-5.3 так же будет работать). Вроде как работает и в 32-х, и в 64-х битах. При компиляции с высокими уровнями предупреждений, конечно же, довольно много ворнингов от компилятора идет, особенно в тестах и примерах. Но вычищать все это ну совсем уже не хочется, да и незачем, думаю.

В общем, мораль сей басни: программа - не воробей, выпустишь - не поймаешь будешь фиксить потом, даже когда захочешь забыть, что же это такое :)

---

PS. В репозитории SObjectizer-а -- это первый проект, в котором зависимости подтягиваются через MxxRu::externals. Вот здесь можно глянуть, как это выглядит. В том числе подтягивается и такая "тяжелая" зависимость, как ACE.

[prog.c++] Обнаружил в одном старом проекте...

Довелось обновить один старинный проект дабы он компилировался современными C++ компиляторами. Судя по всему, последняя правка в этом проектике была в 2003-ем. Сам же этот проект был переделкой еще более старого кода, корни которого восходят куда-то к средине 90-х (кое где даже использовалось ключевое слово register).

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

// В Visual C++ 6.0 заголовочные файлы cstdio и cstddef не // вводят пространство имен std. А компилятор Borland C++ // вводит, и для доступа даже к size_t нужно использовать // пространство имен std. namespace std {} using namespace std;

Да... Были времена. Про стандарты и соответствие им приходилось только мечтать :)

Но вот что важно: даже сейчас, когда есть необходимость, старинный C++ный код собирается самыми свежими C++ными компиляторами. Что является еще одним объяснением того, что C++ никуда просто так не исчезнет.