[prog.c++] Похоже, наткнулся на баг в С++ компиляторе из Visual Studio 2015 Update 2

Установил себе сегодня Visual Studio 2015 Update 2, попытался скомпилировать SObjectizer. Столкнулся с тем, что перестал работать один из тестов. Тест выбрасывал исключение из функции, которая вызывается из noexcept-функции. Это должно приводить к аварийному завершению теста. Но не приводит.

Грешу на проблему в обновленном VC++, ибо предыдущий компилятор отрабатывал нормально. Грубо говоря, вот такой код:

template< typename LAMBDA, typename MESSAGE > class lambda_as_filter_t : public delivery_filter_t    {       LAMBDA m_filter;    public :       lambda_as_filter_t( LAMBDA && filter )          :  m_filter( std::forward< LAMBDA >( filter ) )          {}       virtual bool       check(          const agent_t & /*receiver*/,          const message_t & msg ) const noexcept override          {             return m_filter(message_payload_type< MESSAGE >::payload_reference( msg ));          }    };

Должен приводить к краху приложения, если при вызове m_filter(msg) выскакивает исключение. Но не приводит.

Если же сделать вот такой workaround:

template< typename LAMBDA, typename MESSAGE > class lambda_as_filter_t : public delivery_filter_t    {       LAMBDA m_filter;       bool       do_check( const MESSAGE & m ) const noexcept       {          return m_filter( m );       }    public :       lambda_as_filter_t( LAMBDA && filter )          :  m_filter( std::forward< LAMBDA >( filter ) )          {}       virtual bool       check(          const agent_t & /*receiver*/,          const message_t & msg ) const noexcept override          {             return do_check(message_payload_type< MESSAGE >::payload_reference( msg ));          }    };

То все начинает работать так, как и ожидалось: приложение падает.

Подозреваю, что здесь сказывается то, что базовый класс, delivery_filter_t, из которого наследуется метод check(), экспортируется из DLL. А конкретные экземпляры lambda_as_filter_t генерируются внутри приложение, которое линкует эту DLL. Но пока минимального примера, явно указывающего наличие этой проблемы, сделать не удалось (я пробовал без DLL-ек, но баг не проявился). Может, однако, еще какие-то проблемы сказываются.

В общем, неприятная штука. Как бы не пришлось себе откатывать VS на Update1.

Upd. Засабмитил в Microsoft. Посмотрим, что ответят. И ответят ли.

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

Очередной список просмотренных за месяц фильмов. В начале, как обычно, идут те фильмы, которые понравились больше.

День выборов 2 (2016). Нормально. Но до уровня первого фильма не дотянули, к сожалению.

Джейн берет ружье (Jane Got a Gun, 2015) и Заброшенный (Forsaken, 2015). Два вполне добротных вестерна. Оба не шедевры, но оба посмотрел с удовольствием.

Дедпул (Deadpool, 2016). Мне показалось, что самая сильная сцена -- это разборка на мосту, которая практически вся была показана в трейлере. В остальном откровенная тупизна, но скрытая под большим слоем черного и несколько пошловатого юмора.

Конец света 2013: Апокалипсис по-голливудски (This Is the End, 2013). Ребята оторвались, сняли совершенно тупую, но смешную комедию с невероятным стебом над самими собой. Особенно доставил Ченнинг Татум :)

В центре внимания (Spotlight, 2015). Тема, конечно же, в фильме поднята не простая. Но вот сам фильм почти не цепляет.

Падение Лондона (London Has Fallen, 2016). Нормальный такой боевичок: стреляют, взрывают, морды бьют. Как раз хороший вариант для просмотра с отключенными мозгами.

Кловерфилд, 10 (10 Cloverfield Lane, 2016). У меня фильм оставил такое же неоднозначное впечатление, как и предыстория, известная у нас под названием Монстро. В общем, ждал большего. А тут довольно средненький фильм на один просмотр.

Бетмен против Супермена: На заре справедливости (Batman v Superman: Dawn of Justice, 2016). Просто откровенная бредятина, даже удивительно, как решился такое посмотреть.

Боги Египта (Gods of Egypt, 2016). Редкая ерундистика. Даже спецэффекты не спасают.

[prog] Mxx_ru 1.6.9

Mxx_ru обновился до версии 1.6.9. В этой версии реализована поддержка звездочек в именах, указываемых в map/map_dir и map_file (подробнее в предыдущем посте).

Установить Mxx_ru можно командой gem install Mxx_ru

Обновить Mxx_ru можно командой gem update Mxx_ru

Так же Mxx_ru можно загрузить с SourceForge (gem-файл).

PS. Документация пока не обновлялась из-за отсутствия времени :(

[prog.c++14] Хабровские примеры из батла Go vs D, но на SO-5.5.16

На Хабре обнаружилась статья, в которой рассматриваются реализации на Go и D одних и тех же простеньких примеров из области многопоточности.

Меня лично статья удивила. Мне почему-то казалось, что на D такие игрушечные примеры должны получаться короче и проще. Но, надеюсь, автор статьи лучше понимал, что и как он делает. Мой же интерес в том, чтобы проверить возможности SO-5 на этом же поле.

Для чего на SO-5 было реализована два примера. Краткий их разбор под катом. Взять поиграться их можно из github-овского репозитория (для сборки нужны Ruby+rake+Mxx_ru, заодно там возможности MxxRu::externals можно увидеть).

[prog] По следам опыта с Mxx_ru-1.6.8 и перед релизом Mxx_ru-1.6.9

Накопился некоторый, пусть и небольшой, опыт работы с MxxRu::externals из Mxx_ru-1.6.8. Хорошая новость: externals-ы таки работают. А вот плохих новостей нет :)

Однако, уже очевидно, что некоторые доработки нужны.

Прежде всего, оказалось желательно разрешит переименования исходного каталога в команде map_dir. Например, был каталог some-prj/src/lib, захотели, чтобы он скопировался просто в some-prj/src. Версия 1.6.8 это не позволяла делать.

Так же несколько утомляет необходимость писать имя копируемого файла и в источнике, и в приемнике для map_file. Т.е., когда несколько раз напишешь что-то вроде e.map_file 'prj/src/h/config.h' => 'h/config.h', то это надоедает.

В связи с этим сделаны наметки версии 1.6.9, в которой реализованы решения для двух вышеуказанных случаев:

MxxRu::arch_externals :libmosquitto do |e|   e.url 'http://mosquitto.org/files/source/mosquitto-1.4.8.tar.gz'   e.map_dir 'lib/*' => 'dev/libmosquitto/src'   e.map_file 'config.h' => 'dev/libmosquitto/*' end

Т.е. если в параметре src для map_dir последним элементом является звездочка, то считается, что в dst задано новое имя для исходного каталога. В данном примере каталог lib копируется в каталог dev/libmosquitto под именем src.

Если в параметре dst для map_file последним элементом является звездочка, то считается, что имя файла при копировании должно сохраниться. Т.е. в примере выше файл config.h будет скопирован в файл dev/libmosquitto/config.h.

Лично мне пока оба решения нравятся. Вроде бы просто и понятно, плюс совместимость не нарушается. Но это мое мнение. Интересно и другие мнения послушать. Если есть противопоказания, то проще сейчас все переделать, а не после того, как версия 1.6.9 будет зафиксирована.

В общем, если не будет никаких возражений, то через два-три дня версия 1.6.9 с этими двумя нововведениями выйдет в свет.

Но есть так же еще несколько соображений, которые имеет смысл обдумать и, может быть, реализовать в последующих версиях...