[prog.c++11] SObjectizer обновился до версии 5.5.10

Состоялся релиз версии 5.5.10. В этой версии реализована всего одна новая вещь: возможность указать, какой тип объекта синхронизации должен использоваться MPSC очередями сообщений.

[prog.c++11] Поменяем схему релизов SObjectizer-5.5.*

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

В связи с этим на SF.net будет выкладываться всего три архива: zip-файл с полными исходниками, zip-файл с бинарниками для x86 и zip-файл с бинарниками для x86_64. Бинарники будут собираться MSVS2015 (т.е. VC++14.0). Если кому-то нужны другие типы архивов (со сгенерированной doxygen-ом документаций или бинарные сборки для MSVS2013 (т.е. VC++12.0), то дайте знать. Собрать и выложить их не проблема, если это кому-то нужно.

Больших анонсов на профильных форумах так же не будет. Максимум -- это обновления для уже начатых тем.

Ближайший релиз, версии 5.5.10, если все будет нормально, состоится завтра или послезавтра. А потом, еще через несколько дней, релиз версии 5.5.11.

[prog.thoughts] Новостью про выход Pyston 0.4 навеяло

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

[prog.c++11] Потупил над condition_variable, unique_lock и defer_lock/adopt_lock

Дизайн std::condition_variable в C++11, как по мне, продиктован интересной смесью POSIX-овских стандартов и C++ной идиомы RAII. Из-за этой смеси метод condition_variable::wait требует не std::mutex, а std::unique_lock<std::mutex> (тогда как в POSIX функция pthread_cond_wait получает мутекс напрямую).

Подход C++11 удобен в подавляющем большинстве случаев, т.к. wait нужно вызывать под уже захваченным мутексом, а захват мутекса unique_lock-ом -- это эффективно, просто и безопасно. Но вот довелось оказаться в несколько необычной ситуации: потребовалось задействовать condition_variable::wait() в отсутствии unique_lock-а. Тут-то и столкнулся с собственной тупизной и, отчасти, законом дырявых абстракций... :)