пятница, 27 октября 2017 г.

[prog.c++] Библиотека timertt обновилась до версии 1.2.0

Мы обновили свою легковесную библиотеку для работы с отложенными и периодическими таймерами (wallclock-таймеры не поддерживаются в принципе). В этой версии добавлены две важные фичи:

1. Раньше действие для таймера всегда имело тип std::function<void()>, что было гибко и удобно, но имело скрытые накладные расходы, связанные с std::function (по сути, std::function тут выступал как умный указатель для лямбд и функторов). Если от этих скрытых расходов хочется избавиться, то можно задать свой собственный тип. Например:

class operation_canceler {
    operation_manager & manager_;
    operation_id id_;
public:
    operation_canceler(operation_manager & manager, operation_id id)
        : manager_{manager}, id_{id}
    {}
    void operator()() const noexcept
    {
        manager_.cancel(id_);
    }
};
...
// Define type of timer thread which was use operation_canceler as
// a timer action type.
using my_timer_wheel_thread = timertt::timer_wheel_thread_template<
    operation_canceler,
    timertt::default_error_logger,
    timertt::default_actor_exception_handler >;
...
// Create and use this timer thread.
my_timer_wheel_thread tt;
tt.start();
...
tt.activate( std::chrono::milliseconds(750), operation_canceler{manager, current_id});

Тип должен быть Moveable и MoveConstructible. Соответственно, теперь когда создается объект-таймер, там резервируется место для пользовательского объекта-функтора. А при активации таймера пользовательский функтор мувится в этот зарезервированный кусок памяти. Тем самым не происходит дополнительных аллокаций памяти (как это временами может происходить с std::function).

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

void do_something_complex() {
    timertt::default_timer_wheel_thread tt;
    tt.start();
    ...
    timertt::default_timer_wheel_thread::scoped_timer_object timer;
    // Activate
    tt.activate(timer, std::chrono::milliseconds(250), ...);
    ...
    // Timer can be deactivated in usual way.
    tt.deactivate(timer);
    ...
    tt.shutdown_and_join();
}

Правда, в этой версии мы несколько сломали совместимость на уровне исходного кода. Поэтому номер версии 1.2.0, а не 1.1.4.

Пару слов о происхождении и назначении библиотеки. Когда-то мы долго и с удовольствием использовали большую библиотеку ACE. В том числе и тамошние таймеры (реализация которых была добротной и продвинутой). Но по мере перехода на C++11 мы постепенно отказывались от ACE и в один прекрасный момент оказалось, что из ACE нам нужны только таймеры. Чтобы не таскать дистрибутив ACE только ради таймеров, мы сделали свою легковесную header-only либу, которая базируется только на штатных возможностях C++11.

У нас timertt в работе уже года три. Проблем не замечено. Работает стабильно, может поддерживать изрядное количество таймеров (десятки и сотни миллионов). Реализует три разных таймерных механизма: wheel, heap и list, каждый из которых хорош в своей ситуации.

Предыдущие версии timertt могли работать и с компиляторами, которые не очень хорошо поддерживали C++11 (в частности, VS2013). Начиная с 1.2.0 мы на такие компиляторы уже не оглядываемся. Нужно что-то более-менее нормальное (gcc 4.8-7.2, clang 3.5-5.0, vs2015/2017). Однако, основная часть кода пока еще под все возможности C++ (вроде noexcept и constexpr там, где это разумно) еще не адаптирована. Сделаем это со временем.

Новые фичи были только-только добавлены. Наверняка что-то можно улучшить и сделать удобнее. Это мы так же сделаем со временем, а если будет положительный фидбэк, то это произойдет быстрее.

Архивы с исходниками библиотеки можно найти здесь. Сами исходники живут здесь. Документация здесь.

суббота, 21 октября 2017 г.

[prog.memories] С++ с 1985-го по 2017: краткая ретроспектива

В процессе подготовки доклада к GECon-2017 раскопал небольшой список основных, на мой взгляд, вех в развитии C++. Вроде как этот список впервые был написан для RSDN-а, ну и для того, чтобы искать его было проще, решил утащить в блог.

Любопытно, что если выбрать любую временную точку из истории развития C++, то в ней будет свое понятие "modern C++". Хотя у тех, кто оказался покусан Александреску и все еще находится в здравом уме и трезвой памяти, "modern C++" все-таки связан с тенденциями, которые начались в начале 2000-х именно с книги Андрея Александреску "Modern C++ Design" (хотя корни, по моему, уходят в 1992-1993, когда Алекс Степанов взялся за STL на C++). Ну и как по мне, только где-то с C++14 язык C++ стал достаточно удобным для того, чтобы описанные Александреску в 2001-ом году приемы могли бы использоваться массово. Но это мое личное мнение, никому его не навязываю.

Вот, собственно, моя краткая ретроспектива основных вех в развитии C++:

  • С++ вышел в свет в 1985-ом году, без множественного наследования, пространств имен, шаблонов и исключений;
  • в 1988-ом году в C++ добавилось множественное наследование, const-методы, protected-модификатор;
  • в 1990-ом в C++ добавили пространства имен, шаблоны и исключения. Где-то через год-полтора после этого Степанов выбрал C++ в качестве языка для своих экспериментов в области обобщенного программирования (используемые до этого Степановым Scheme и Ada оказались недостаточно(!) выразительными для этого);
  • в 1993-ом году про STL Степанова стало известно и начались работы по включению STL в стандарт C++;
  • в 1994-ом году выходит "Design and Evolution of C++", в которой Страуструп говорит о C++, как о мультпарадигменном языке программирования. И о том, что не следует относиться к C++ как к "чисто объектно-ориентированному" или "чисто процедурному" языку программирования;
  • где-то в 1994-1995-годах в C++ случайно открыли такую штуку, как template metaprogramming. Что дало старт теме программирования на C++ных шаблонах;
  • в 1998-ом году зафиксирован стандарт C++98, в котором оказался STL от Степанова (причем и сам STL был доработан, и C++ был "дотянут" до того, чтобы уметь поддерживать STL);
  • в 1999-ом году началось развитие Boost-а. В качестве полигона для новых идей для C++. Откуда затем в стандарт C++ придут shared_ptr и пр.;
  • в 2001-ом году вышла книга Александреску "Modern C++ Design", которая максимально популяризировала тему программирования на C++ных шаблонов (этой теме к тому времени уже было порядка 7 лет);
  • в 2003-ом году был зафиксирован корректирующий стандарт C++03. Приблизительно тогда же более-менее полные реализации C++98 стали доступны на большинстве платформ;
  • 2003-й год: в Boost попадает MPL -- фреймворк для метапрограммирования на шаблонах;
  • в 2003-ом году в свет выходит LLVM, проект, который затем попадет под крыло Apple и приведет к появлению clang;
  • 2004-2005-й годы: Boost становится двигателем новых библиотек в стиле Modern C++, изрядная часть Boost-а представляет из себя header-only библиотеки шаблонов;
  • в 2007-ом году появляется первая публичная версия компилятора clang. Который стал очень быстро развиваться и быстро стал основным компилятором для платформ от Apple, затем для FreeBSD и, позднее, для Android-а. Появление clang-а очень сильно подстегнуло развитие других мейнстримовых компиляторов, в первую очередь GCC и MSVC;
  • 2011-й год: стандарт C++11. Целая куча нововведений, расширяющих возможности шаблонов и метапрограммирования: variadic templates, constexpr, auto, decltype, ...;
  • 2014-й год: стандарт C++14. Еще больше возможностей для шаблонов и метапрограммирования, в частности, снятие ряда ограничений для constexpr, более простой auto для функций;
  • 2015-2016: появление библиотек вроде Boost.Hana;
  • 2017-й: зафиксирован драфт стандарта С++17, значительная его часть уже доступна в GCC и Clang, часть проектов уже активно использует C++17 в продакшене.

Если вы выделяете какие-то другие вехи в развитии C++, то не сочтите за труд поделиться в комментариях. Ну, например, появление такой штуки, как expression templates, библиотека MFC, начало использования C++ в разработке операционных систем Windows и BeOS, библиотека Qt, среда KDE, проект LLVM, решение о переходе на C++ в GCC и т.д.

четверг, 19 октября 2017 г.

[prog.c++] Буду выступать на GECon-2017

Компания EPAM проводит вторую большую ИТ-конференцию у нас в Гомеле: GECon-2017.

Я там собираюсь сделать доклад на тему "C++ -- монстр, которого никто не любит, но который всех переживет". Где собираюсь рассказать о том, как C++ стал мейнстримом, как он развивался, к чему пришел, где применяется, какое будущее его ждет и как C++ выглядит на фоне имеющихся конкурентов (в первую очередь C, D, Go, Rust).

В общем, к чему я это? А к двум вещам:

Во-первых, если кто-то еще не слышал про проведение GECon-2017 у нас в городе, то теперь вы знаете. Имеет смысл прийти и послушать. В прошлом году было более чем любопытно, и сама конференция была организована очень хорошо.

Во-вторых, если кто-то поделится какими-то интересными примерами использования C++ или интересными примерами того, как современный C++ упростил вам работу, то поделитесь, пожалуйста. Не сочтите за труд. У меня есть свои примеры, конечно же, но все равно чем больше таких примеров будет перед глазами, тем интереснее получится доклад. Ну вот, например, несколько лет назад было интересно узнать, что Dropbox стал активно использовать C++ для разработки мобильных приложений. Выгода здесь в том, что ядро приложение пишется всего один раз и остается общим для всех платформ, а уже GUI-часть навешивается своя для каждой платформы. Или другой пример: на одной из CppCon (вроде бы 2015-го года) был доклад о использовании C++ на больших вычислительных кластерах для расчета прогнозов погоды. Вот за такого рода примеры я буду сильно признателен.

Как, кстати говоря, и обратным примерам. Типа того, что вот была система на C++ и все просто замучались ее поддерживать, потом посадили 3-х вчерашних студентов и они все за месяц переписали на Go, после чего волосы у всех стали мягкими и шелковистыми, а стул нормализовался... ;) Серьезно, на C++ я давно смотрю без розовых очков и хочу сделать более-менее объективый доклад, а не агитку о том, как же все круто в C++ (на самом деле нет).

вторник, 17 октября 2017 г.

[prog.wtf] Городские легенды про "гения, из-за которого мы все просрали..."

Прочитал вот это: We fired our top talent. Best decision we ever made. Захотелось высказаться.

Всю мою карьеру меня преследует опасение, что я слишком увлекаюсь велосипедостроением. Действительно, из моих рук в разное время выходили: собственный текстовый редактор, собственная оконная библиотека (две), собственная объектная СУБД (две), собственная система сборки (много, включая одну, для которой был сделан свой язык программирования), собственный векторный графический редактор. Ну и это не говоря про SObjectizer. В общем, повелосипедил я изрядно.

Ну что уж тут поделать, не нравятся мне задачи, где нужно комбинировать готовые компоненты. Есть такой недостаток. Зато у меня получается сделать что-то из ничего. Иногда в буквальном смысле. Иногда чужими руками (это я сейчас про тот же SObjectizer-5 и RESTinio).

Добавим сюда еще и неприятную предрасположенность к рефлексии и самокопанию, и получается, что довольно-таки часто мне приходится самому перед собой отчитываться о том, а не страдаю ли я откровенной херней? И не пора ли принять какое-то сильнодействующее лекарство от NIH syndrome...

Что меня в таких сеансах самокопания всегда спасало, так это то, что практически все велосипеды доводились не просто до работоспособного состояния. Они потом еще и работали. Иногда годами. Иногда серьезно развиваясь и видоизменяясь. Уж не знаю, чего это стоило тем коллегам, которым приходилось мои творения использовать, но факт оставался фактом: велосипеды быстро достигали работоспособного состояния и в таком состоянии старательно поддерживались.

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

Вот и в статье, ссылку на которую я дал вначале, самым удивительным и непонятным для меня оказалось вот что: как вообще в современных условиях компания, в которой был менеджмент, была какая-никакая, но командная разработка, шли параллельно несколько проектов и т.д. (нет ощущения, что это стартап из 3-х человек, в котором всего один программист) получилось так, что у них образовался проект с постоянно сдвигающейся датой релиза? Из того, что я слышал про современные корпоративные порядки, такое сейчас вряд ли возможно даже в распильных проектах в российских госкорпорациях. В общем, я бы хотел хоть раз в жизни попасть на проект, в котором можно кормить завтраками ПМов и заказчиков (пусть даже и внутренних) в течении хотя бы года и получать деньги за то, чтобы делать с нуля все, что только вздумается. Это, блин, какая-то фантастика :)

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

PS. А вообще, если кому-то нужно сделать с нуля что-то свое (может быть совершенно новое, может быть не сильно новое, но свое), имея только более-менее осознанное понимание, зачем вам это нужно, то есть люди, которые умеют и любят такие задачи ;) Правда, осознанное понимание таки необходимо, поскольку люди эти работают не за бесплатно. Но с нуля до рабочего состояния сделать могут.

PPS. Таки да, это явная и неприкрытая джинса. Проплачена мной :)

воскресенье, 15 октября 2017 г.

[prog.c++] Кратко о прошедшей конференции C++ CoreHard Autumn 2017

Если кратко, то было круто. За что огромное спасибо и организаторам, и коллегам-докладчикам, и посетителям!

У нас было три выступления, одно большое и два блица, так что сложилось ощущение, что вся конференция промелькнула как будто за пять минут: не успели прослушать один доклад, как нужно читать свой, не успели перевести дух -- нужно читать следующий, не успели отчитаться, бах! И все закончилось... Нам, правда, еще повезло, мы еще и на афтерпати попали, но и афтерпати промелькнуло еще быстрее.

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

Для конференции мы подготовили приз за самый оригинальный вопрос. Вот такой:

20171002-142120-DSCF8632

Чистой воды хэнд-мейд и самый что ни есть эксклюзив ;) Сделанный настоящим мастером Антоном Хандожко под заказ по индивидуальному эскизу. И, понятное дело, приз нашел своего обладателя:

20171014-183036-DSC_9751

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

В принципе, про Модель Акторов в рамках C++ CoreHard мы рассказали все, что хотели. И, если представится возможность выступить на C++ CoreHard в следующем году, то мы постараемся рассказать еще о чем-нибудь интересном. Например, о том, как C++ помогает в разработке и сопровождении кода. Время от времени я об этом писал в блоге в "рубрике" с общей темой "Шаблоны против копипасты". Полагаю, из этого можно будет сделать полноценный и интересный доклад. Или о том, чего стоит разработка своего встраиваемого HTTP-сервера на C++, который бы, с одной стороны, предоставлял простой и удобный интерфейс программисту, а, с другой, был бы сильно кастомизируемым и применимым, в том числе, и для больших нагрузок. Естественно, все это не без помощи современного C++ и шаблонной магии...

Ну и напоследок еще раз выскажу благодарность сообществу corehard.by, которое умудряется проводить такие крутые и нужные мероприятия. Ребята вы прям ну очень крутые, спасибо за то, что вы делаете!

пятница, 13 октября 2017 г.

[prog.c++] Конференция C++ CoreHard Autumn 2017 уже завтра

Завтра, 14-го октября, в Минске пройдет очередная конференция для C++ разработчиков "C++ CoreHard Autumn 2017". Stiffstream там будет представлен сразу тремя выступлениями.

Во-первых, большим докладом "Actors for fun and profit", в котором я буду рассказывать о том, как понять, принесет ли Модель Акторов вашему проекту fun и profit, или же вы поимеете неприятности на свою голову. Кстати говоря, у нас заготовлен специальный памятный, очень аутентичный приз за лучший вопрос докладчику, так что не упустите свой шанс! ;)

Во-вторых, двумя блиц-докладами. Первый блиц-доклад будет посвящен restinio, нашему инструменту для встраивания http/websocket сервера в C++ приложение. Благо очередная версия, 0.3, в которую мы добавли поддержку websocket-ов и некоторые другие вкусности, уже стабилизировалась и мы активно верстаем документацию для того, чтобы сделать публичный релиз уже в начале следующей недели. Второй блиц-доклад будет про MxxRu::externals. Это та простая система управления зависимостями, которой мы успешно пользуемся уже более полутора лет. И которая отличается от conan-ов, hunter-ов, cppan-ов, vcpkg и пр. отсутствием надобности каких-либо централизованных репозиториев пакетов и какого-либо специального оформления этих самых пакетов.

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

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

среда, 11 октября 2017 г.

[prog.c++] Давайте говорить dependency manager for C++ вместо package manager for C++?

Why is the committee not in charge of a build system and a package manager?

Почитал эту тему на reddit-е. Показалось, что у некоторых красноглазых линуксоидов личностей, особенно из мира Linux и OSS, какая-то идиосинкразия на термин package manager. Они прям начинают исходить на говно при попытке обсудить package manager для отдельного языка программирования (не важно, будет ли это C++, Rust, Ruby или Haskell). Ибо package manager -- это неотъемлимая часть их теплого и уютненького дистрибутива Linux-а. А все, что вне этого есть ересь и блуд.

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

Ну чтож, мир нужно воспринимать как он есть. Посему, раз существуют подобные "седые горлопаны, мудрые как эпос"(с), то имеет смысл перестать в разговорах про управление зависимостями в C++ употреблять термин package manager. Предлагаю использовать термин dependency manager. И пусть никто не уйдет обиженным: C++ разработчики будут использовать dependency manager для того, чтобы разруливать зависимости для своего кода, а ярые защитники пакетных менеджеров затем будут опакечивать результаты работы C++ разработчиков посредством своих любимых package manager-ов.