[prog.c++] Проверки на noexcept "для бедных"

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

Многие жалуются, что в коде не видно, откуда исключения могут вылететь. ИМХО, это просто из-за недостатка опыта. Если заставить себя думать о том, что исключения могут вылететь откуда угодно, то со временем к этому привыкаешь. И начинаешь понимать, что на самом деле гораздо более важно иметь возможность увидеть, откуда исключение вылететь не может.

В C++11 в этом направлении сделали важный шаг: добавили в язык спецификатор noexcept. Так что теперь из прототипа функции можно узнать о том, что она исключений не бросает.

Но, к сожалению, лично для меня этого спецификатора недостаточно. Поскольку люди совершают ошибки. И, например, написав вот такой простой код:

void some_complex_class::cleanup() noexcept {    cleanup_part_one();    try {       cleanup_part_two();       cleanup_part_three();    }    catch(...) {} // Just ignore exceptions.    cleanup_part_four(); }

Можно легко накосячить.

[prog.c++] Небольшое, но важное обновление для SObjectizer-а.

Мы обновили SObjectizer до версии 5.6.1. Изменений совсем мало, просто дошли руки сделать фичу, которая не попала в релиз 5.6.0 из-за недостатка ресурсов при подготовке ветки 5.6. Но зато это первая версия, которая была разработана на GitHub после того, как Atlassian заявил о запланированном удалении Hg-репозиториев с BitBucket-а. Так что теперь дальнейшее развитие SObjectizer-а и so5extra будет происходить на GitHub-е, а SouceForge будет служить зеркалом для тарболлов.

Ну и по поводу дальнейшего развития SObjectizer-а нужно сказать важную вещь: в SObjectizer/so5extra мы реализовали практически все, что нам хотелось. Больше никаких серьезных нововведений не планируется. Мелкие дополнения и исправления будут время от времени вноситься, но появления больших фич, вроде msg_tracing-а, наверное, можно не ждать. Мы пока и сами не знаем, чего такого-этакого в SObjectizer можно (и нужно) добавить.

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

Ну, например, время от времени высказывается сожаление о том, что SObjectizer завязан на реализацию многопоточности из C++ной стандартной библиотеки. Т.е. на std::thread, std::mutex и вот это вот все.

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

Еще одно возможное направление развития -- это попытка адаптировать SObjectizer под нужды систем реального времени. В частности, введение таких механизмов в работу SObjectizer-а, которые бы не использовали динамическую память (либо использовали бы ее только во время старта). Но и здесь такая же ситуация: без конкретного "заказчика" ввязываться в такую серьезную переделку мы не готовы.

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

Сообщить нам о том, чтобы вы хотели видеть в SObjectizer-е можно через Issues на GitHub, соответствующую Google-группу, Feature Requests на SourceForge. Так же, напомню, что наша компания осуществляет поддержку SObjectizer-а и so5extra (как и других наших продуктов). Так что если вы хотели бы иметь кастомизированную версию SObjectizer-а под свои нужды или вам нужна наша помощью в разработке вашего продукта, то с нами всегда можно договориться ;)

[life.cinema] Очередной кинообзор (2019/08)

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

Мертвые не умирают (The Dead Don't Die, 2019). Укуренный фильм про зомби от укуренного режиссера, известного своими укуренными фильмами. Зайдет точно не всем. Поэтому рекомендовать не могу. Мне показался слишком скучноватым, хотя некоторые моменты улыбнули.

Мышеловка (4x4, 2019). Аргентино-испанская попытка снять драму+триллер на остросоциальную тему. Получилось не очень. Хотя, возможно, это просто в наших палестинах уровень преступности пока еще не достиг такого уровня, как в Испании, поэтому острота поднятой в фильме проблемы не ощущается.

Люди Икс: Тёмный Феникс (Dark Phoenix, 2019). Наверное, достаточно добротное продолжение серии фильмов про людей Икс. Но очень уж скучное, чуть не заснул при просмотре. Хотя снято все красиво, этого не отнять.

Форсаж: Хоббс и Шоу (Fast & Furious Presents: Hobbs & Shaw, 2019). Настолько тупая и невероятная сказочка, что на ее фоне даже фильмы про Джеймса Бонда начинают казаться документальными. Отчасти это компенсируется юмором и красивой актрисой в главной женской роли, но лишь отчасти.

Игра Ганнибала (Nomis, 2018). Просто удивительно, как можно было собрать такой звездный актерский состав и снять такое унылое и скучное говно.

[prog.flame] Отличная статья: "How to Build Good Software"

Из этих наших интернетиков принесло ссылку на отличную статью под названием "How to Build Good Software". Статья капитанская. Для тех, кто варится в разработке софта не первый десяток лет, там ничего нового или незвестного нет. Просто хорошая выжимка вещей, продиктованных самим здравым смыслом.

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

Для меня прям бальзамом на душу прозвучало несколько пунктов в статье. Во-первых, про то, что уход разработчиков несет для компании невосполнимые потери в виде потери знаний, которые нигде и никак не были зафиксированы (а зафиксировать все в принципе невозможно). Тут я не буду проявлять скромность и дам ссылку на свой собственный пост в этом же блоге восьмилетней давности как раз на тему важности этих знаний: [prog;work;thoughts] Прибавка к зарплате “за выслугу лет” программистам, да и не только….

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

В общем, статья хорошая. Прочитать ее полезно. А тем, у кого меньше 10 лет в разработке софта за плечами, так и обязательно ;)