[prog.thougts] В очередной раз о нотации (в применении к C++)

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

Дело в том, что в C++ нет общепринятого и стандартизированного соглашения о стиле оформления кода. На мой взгляд, это есть хорошо, но это мое личное мнение. Важнее то, что в C++ сообществе спокойно сосуществуют и активно используются совершенно разные стили именования. В STL и Boost-е, как мне кажется, традиционный C/C++ стиль. В Qt, wxWidgets и в POCO -- более привычный для Pascal/Delphi/VisualBasic/Java/C#. В библиотеке ACE вообще свой собственный, неповторимый стиль, заимствующий хорошие элементы как из snake_case, так и из CamelCase.

Мы же уже очень давно используем snake_case стиль, но с некоторыми очень важными дополнениями. В частности, у нас для имен типов используются суффикс _t. Например, у нас тип агента называется agent_t, а не agent. А тип сообщения называется message_t, а не message.

К суффиксу _t в мире C++, как мне думается, отношение довольно своеобразное. Давным-давно от суффикса _t стремились отказываться, т.к. это выглядело темным наследием plain old C. В C-шном коде суффикс _t давали, как правило, именам typedef-ов. Например, писали что-то вроде typedef struct my_type {...} my_type_t;.

Но в последние годы, после выхода C++11 и, особенно, после выхода C++14, суффикс _t в C++ опять возвращается, но уже в специфической роли. Например, начиная с C++14 в стандарт языка добавляются сокращенные определения, вроде enable_if_t<C,T> вместо enable_if<C,T>::type. Так что теперь в C++ для суффикса _t появляется вполне определенная нише. И использование данного суффикса для других целей способно запутать стороннего разработчика (разорвать шаблон, так сказать).

Чтобы быть "ближе к народу", мы у себя попробовали провести небольшой натурный эксперимент. И для одной своей новой разработки попробовали отказаться от _t в пользу традиционного для STL/Boost стиля именования сущностей.

Результат нам не понравился. И если при написании кода отсутствие суффикса _t хоть и мешает, но приспособиться можно, то вот при чтении кода имена типов без привычного уже суффикса _t крайне тяжело выделять из кода. Так что читать чужой код написанный в стиле STL/Boost значительно тяжелее, чем код в нашей привычной нотации. Посему эксперимент был признан неудачным, код мы вернули к старому оформлению. Причем решение вернуться назад мы приняли намного легче, чем решение провести этот самый эксперимент :)

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

PS. Если бы мне сейчас предстояло выбирать нотацию для C++ного кода, я бы взял уже привычную нотацию со snake_case, с использованием префиксов m_ для полей структур/классов и g_ для глобальных переменных. А вот для пространств имен и имен типов сделал бы небольшое изменение: первая буква в таких именах должна была бы быть заглавной. Получилось бы что-то вроде So_5::Impl::Simple_mtsafe_st_env_infrastructure_details::Actual_elapsed_timers_collector вместо текущего so_5::impl::simple_mtsafe_st_env_infrastructure_details::actual_elapsed_timers_collector_t (имена, кстати говоря, реальные).

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

Вышла обновленная версия библиотеки timertt для работы с таймерами в C++ -- 1.1.2. В этой версии добавлена одна малюсенькая, но очень важная деталь: теперь в классах таймерных нитей и таймерных менеджеров есть публичное имя thread_safety. С его помощью стало гораздо проще писать шаблонный код, который может работать с разными типами таймерных нитей/менеджеров. Например:

// Класс для управления таймерами в прикладной программе. // Может работать с разными типами таймерных нитей или менеджеров. template< typename TIMER_CONTROLLER > class timer_client {    TIMER_CONTROLLER & controller_; public :    // Определяем тип идентификатора с учетом того, какой thread_safety    // используется у менеджера таймеров.    using timer_holder = timertt::timer_holder_object< typename TIMER_CONTROLLER::thread_safety >;    // Создать новый таймер, при срабатывании которого нужно что-то выполнить.    template< typename DURATION, typename ACT >    auto schedule_action( DURATION timeout, ACT && action ) {       timer_holder id = controller_.allocate();       controller_.activate( id, timeout, [act = std::move(action)] {             act();          } );       return id;    }    // Отменить действие, которое было запланировано.    void cancel_action( timer_holder id ) {       controller_.deactivate( id );    }    ... }; using mtsafe_wheel_manager = timertt::timer_wheel_manager< timertt::thread_safety::safe >; timer_client< mtsafe_wheel_manager > client1(...); auto id1 = client1.schedule_action( 250ms, []{ ... } ); ... client1.cancel_action( id1 ); using mtunsafe_wheel_manager = timertt::timer_wheel_manager< timertt::thread_safety::unsafe >; timer_client< mtunsafe_wheel_manager > client2(...); auto id2 = client2.schedule_action( 500ms, []{ ... } ); ... client2.cancel_action( id2 );

Без этого маленького дополнения класс timer_client пришлось бы делать зависящим от двух параметров шаблонов: от самого таймерного механизма и от признака thread_safety. Начиная с версии 1.1.2 достаточно всего одного шаблонного параметра.

Если вдруг кто-то не в курсе, что такое timertt, то в нескольких словах это:

Header-only библиотека без внешних зависимостей, базирующаяся на возможностях стандартной библиотеки C++11. Реализует таймеры на основе тайм-аутов, т.е. таймеры, которые должны сработать через сколько-то миллисекунд (секунд, минут и т.д.) после момента активации таймера. wallclock-таймеры не поддерживаются.

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

Библиотека поддерживает три таймерных механизма: timer_wheel, timer_heap и timer_list, у каждого из которых есть свои преимущества и недостатки. Может поддерживаться большое количество таймеров (десятки и сотни миллионов) и обеспечивается высокая скорость обработки таймеров (до нескольких миллионов в секунду).

Кросс-платформенная, проверялась посредством MSVS2013, 2015, 2017 (Windows), GCC 4.9-6.3 (Windows, Linux), Clang 3.5-3.9 (Linux, FreeBSD).

Распространяется под 3-х секционной BSD-лицензией, может свободно использоваться как в открытых, так и в закрытых коммерческих проектах.

Мы сделали timertt где-то 2.5 года назад, с тех пор она верой и правдой служит нам в SObjectizer-е. Последние правки вносились почти два года назад, когда вышла версия 1.1.1. За все время каких-то проблем с timertt не замечено.

Библиотека разрабатывалась для замены ACE в проекте SObjectizer, поэтому все, что связано с timertt, находится на SourceForge:

• архивы с исходными текстами доступны в секции Files. Архив timertt-1.1.2-headeronly.7z содержит только основной заголовочный файл со всей функциональностью timertt. Архив timertt-1.1.2-full.7z содержит так же тесты, примеры и сгенерированный посредством Doxygen API Reference Manual;
• основная документация для проекта собрана в Wiki;
• исходники лежат в Subversion-репозитории на SourceForge. Релизные версии в tags/timertt, находящиеся в разработке версии в branches/timertt.

[prog.flame] На тему тяжести выбора хороших имен идентификаторов

Как известно, одной из фундаментальнейших проблем в программировании является выбор хороших имен для индентификаторов в программе. Только что признать свое поражение в попытках решить эту проблему в одном частном случае и сделать сделать пространство имен с именем simple_mtsafe_st_env_infrastructure_details и класс с именем simple_mtsafe_st_env_infrastructure_t. Расшифровывается основная часть этого странный набор символов как simple multi-thread safe single-threaded environment infrastructure (т.е. простая реализация однопоточной инфраструктуры для окружения, в которой обеспечивается защита от многопоточного доступа).

Заодно этот пример показывает, почему после многих лет использования CamelCase я в итоге пришел к snake_case. Имхо, идентификатор SimpleMtSafeStEnvInfrastructureDetails был бы ну совсем уж зубодробительным неудобным (из категории прощай зрение).

[life.business] Впечатления от посещенного Startup-Forum-а

Вчера в Минске в EventSpace.by прошел Startup Forum, который мы посетили почти что полным составом своей небольшой компании. Впечатление своеобразные, попробую поделиться.

Прежде всего огромная благодарность организаторам: как всегда в EventSpace все было на отличном уровне.

Главное впечатление же от самого мероприятие таково: посетить нужно было обязательно. Но не столько ради того, чтобы научиться чему-то, сколько для того, чтобы в очередной раз вспомнить, что для успешного продвижения своего дела нужно быть предпринимателем, нужно думать как бизнесмен. Когда практически 95% времени ты связан с технологическим развитием своих продуктов об этом, к сожалению, забываешь. А тут был хороший повод вспомнить об этом.

Было два очень интересных выступления. Первое от Максима Каменкова, второе от Кирилла Волошина (того самого, одного из основателей tut.by). Выступление Кирилла Волошина, как мне показалось, было просто на голову выше всех остальных. Чувствуется просто колоссальный опыт выступления на публике, умение доносить свои мысли до слушателей, держать контакт с аудиторией и оперативно реагировать на реплики из зала.

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

Чего мне не хватило в выступлениях от опытных стартаперов, так это отдельного акцента на том, что для успеха нужна серьезная увлеченность своей идеей. Я бы даже сказал фанатичная увлеченность тем, что ты делаешь. Намеки на это звучали в ряде выступлений, но скорее под соусом того, что нельзя сдаваться, нужно находить в себе силы и желание продолжать. Однако, прямо не было сказано, что от основателя требуется готовность жить своим делом в режиме 24/7.

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

Мне представляется, что лет 30 назад (может раньше, может позже) на Западе пришло понимание, что для успешного выращивания стартапов нужно переходить к квадратно-гнездовому методу массовому их разведению. Полагаю, это было неизбежно. Вряд ли есть какие-то хорошие методы оценки перспективных новых начинаний для того, чтобы проводить хороший отсев жизнеспособных идей от нежизнеспособных. Чтобы из 100000 стартапов отобрать 100, из которых более-менее успешными окажутся 50. Проще и перспективнее дать возможность стартовать 50000 стартапов, из которых умрут 49000, оставшаяся 1000 выживет, а из этой тысячи штук сто окажутся очень успешными.

Однако, при таком массовом производстве неизбежно возникает некая индустрия раздачи денег стартапам. Формируются некоторые правила игры, некоторые алгоритмы поведения, по которым живут венчурные фонды и бизнес-ангелы для того, чтобы вкладывать деньги, получать прибыль и снижать свои риски.

При этом, однако, формируется и обратная сторона: т.е. оформляются правила игры и для стартаперов для того, чтобы с высокой долей вероятности попасть в списки тех, кто таки сумел выбить финансирование от инвесторов. И за последние лет 20 основной целью стартап-тусовки стало обучение стартаперов правилам этой самой игры. Поэтому, когды ты сам сталкиваешься с этим всем, то начинает казаться, что акценты расставляются не там. Людей учат тому, как получить инвестиции, как очаровать инвесторов, как сохранить репутацию, если стартам все-таки не взлетит.

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

Другое дело, что вам могут потребоваться инвестиции. Например, вам нужно закупить оборудование для производства товаров, арендовать складские помещения, нанять персонал и т.д. Тут да, тут придется научиться правилам игры. Но сперва у вас должно возникнуть четкое понимание что и зачем вам нужно. Как правильно сказали на форуме -- деньги инвесторов -- это горючее, которое вы зальете в свою машину для того, чтобы ехать быстрее. Но "своя машина" -- это то, что должно появиться у вас еще до того, как вы пойдете просить деньги на горючее. Хотя бы в виде идеи, проработанной с достаточной степенью детализации (для чего и нужно жить своей идеей в режиме 24/7).

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

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

PS. Перед тем, как начать писать данную заметку, наткнулся на замечательную статейку в FB. Как по мне, так она просто из категории must read.

[life.book] Дочитал книгу "Стив Джобс. Уроки лидерства"

Дочитал книгу Уильяма Саймона и Джея Эллиота "Стив Джобс. Уроки лидерства". Интересно. Но я бы рекомендовал ее как дополнение к другой книге, "Стив Джобс" Уолтера Айзексона.

Книга Айзексона говорил о разных сторонах Джобса: и как о человеке, и как о бизнесмене. А вот книга Эллиота больше рассказывает о том, какие решения Джобс принимал и какие шаги предпринимал как предприниматель и как лидер и вдохновитель знаковых проектов компании Apple (а так же компаний Pixar и NeXT). В результате обе книги очень хорошо дополняют друг друга.

По-моему, я нашел хорошее описание того, чем же "брал" Джобс. Вот характерный фрагмент, который, имхо, отлично раскрывает самые сильные стороны Джобса. Речь идет о моменте истории Apple в середине 90-х, когда Apple искала для своих компьютеров новую операционную систему. В результате отбора осталось два претендента: NeXT от Стива Джобса и BeOS от Жана-Луи Гассе. И вот как описывается в книге финальное сражение между Джобсом и Гассе:

«Перестрелку в О.К. Коррал» назначили на 10 декабря 1996 года. Стива и Жана-Луи пригласили сделать презентацию своих продуктов на решающем совещании, которое должно было состояться в Пало-Альто, в отеле Garden Court (это место выбрали специально для того, чтобы сбить со следа журналистов).

Стив взял с собой своего гения операционных систем Ави Теваньяна. Столы в зале были расставлены буквой «П», и Стив вместе с Ави разместился в центре, а Джил и Эллен — в конце стола. Эксперт Apple по программному обеспечению Уэйн Мерецки сидел примерно посредине боковой линии столов. Он так описывает эту сцену: «Презентация Стива полностью сосредоточилась на Джиле, будто, кроме него, в зале никого не было. Стив, как и следовало ожидать, проявил абсолютное спокойствие, когда расхваливал преимущества своей операционной системы». Он изложил суть основных характеристик NeXTStep, делавших ее подходящей для Apple, а затем показал на ноутбуке, как эта операционная система может проигрывать два кинофильма одновременно… после чего запустил еще три фильма. Пять фильмов демонстрировались бок о бок на одном компьютере. Все присутствующие прекрасно поняли, насколько ценным для Apple было программное обеспечение, которое могло поддерживать такие вычислительные возможности.

Уэйн продолжает: «Стив использовал все возможные средства, и его презентация, которую он проводил при непосредственном участии Ави, в очередной раз подтвердила, что он по меньшей мере лучший торговый агент и лучший оратор в сфере технологий. Гассе пришел на эту встречу сам, без заранее подготовленного выступления, и только отвечал на вопросы». Он просчитался, полагая, что у Apple нет другого выбора, помимо операционной системы BeOS. Он не выдвинул никаких весомых аргументов, которые объясняли бы, почему BeOS и только BeOS необходима Apple.

Уэйн Мерецки сказал по этому поводу следующее: «Решение в пользу NeXT, а не Be Inc., стало очевидным».

Итак, для меня все точки над "i" расставила одна короткая фраза: "он по меньшей мере лучший торговый агент и лучший оратор в сфере технологий".

Однако, книга "Стив Джобс. Уроки лидерства" оказалась для меня интересна не только поисками ответа на вопрос "чем же так велик Стив Джобс?" Она интересна еще и тем, что практически на всем ее протяжении Джей Эллиот, работавший рядом с Джобсом, рассказывает о решениях, которые принимались и претворялись в жизнь Джобсом. Это заставляет задумываться о том, а как бы ты сам поступал, на что ты готов пойти, что для тебя самое важное, ради чего ты сам занимаешься тем, чем занимаешься, хочешь ли ты этим заниматься и т.д., и т.п. В этом смысле мне даже показалось, что заключительная треть книги даже интереснее чем первые две трети.

В общем, резюмирую: если книга Айзексона про Джобса уже прочитана, то эта книга Эллиота будет отличным дополнением к написанному Айзексоном портрету Джобса. Если же книгу Айзексона еще не читали, но тема достижений Джобса интересна, то я бы рекомендовал бы прочесть сперва книгу Айзексона, а уже следом книгу Эллиота.

[prog.flame] Вся сущность Хабра в одной ссылке

Интересная площадка, этот самый Хабр. Со временем лучше становится понятно, почему бывалые RSDN-еры и LOR-овцы отзываются о Хабре негативно. Квинтэссенцией на данный момент для меня стала вот эта статья на Хабре и ее обсуждение: "О чём молчат авторы «Hello, World!»-ов".

Сперва автор исходя из лучших побуждений, полагаю, написал откровенно слабую статью, без нормального введения, развития, кульминации и отчетливого вывода. Потом в комментариях начался треш и угар от публики, которая, очевидно, ни сном, ни духом о том, в каких условиях и как создавался язык Ada, и какую роль он играл в свое время в американском ВПК, да не только там, но и в разработке ПО для авионики во всем мире (может быть за исключением СССР и СНГ). Не удивлюсь, что все отметившиеся там комментарии (включая меня самого) и в кошмарном сне не смогут представить себе, что значит разработка ПО для проекта стоимостью в полмиллиадра долларов (вроде бы столько стоил взорвавшийся на старте Ариан 5, ПО для которого было написано как раз на Ada). Посему и вопросы в камментах из категории: а есть ли в Ada map/filter на лямбдах?

Тем, кто хоть чуть-чуть интересуется историей развития языков программирования очень рекомендую почитать про историю Ada. Ведь язык появился в результате попытки министерства обороны США упорядочить ситуацию с разработкой ПО для нужд армии. До появления Ada там царил хаос и анархия: каждый подрядчик использовал свои языки и технологии, никого не волновало, как именно будут сопрягаться разрозненные части одной и той же системы, созданные разными исполнителями в разных концах США. Создание Ada и ее насаждение в проектах для армии США, как по мне, сродни введению системы калибров и унификации артиллерийских систем в армиях самых продвинутых европейских стран в XVII-XVIII веков.

Язык Ada, действительно, является продуктом "разработки коммитетом", поэтому он выглядит достаточно страшно. Многословен, непрост в изучении, требует внимания при разработке. У современных хипстеров, эстетическое восприятие которых воспитано девайсами от Apple, может вызвать неудержимый рвотный рефлекс.

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

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

Ну, некоторые умельцы умудряются и на Java делать системы реального времени. Правда, превращая Java в какое-то убогое подобие недосишки/недоплюсов, выбрасывая GC и вручную колупаясь с байтами, не имея при этом нормальных средств для того же обобщенного программирования. Причем началось все это где-то лет через 20 после того, как Ada появился и начал успешно использоваться. Подозреваю, что на технике из середины 80-х годов, Java оказалась бы неприспособленной к массовому использованию чуть меньше, чем полностью.

А вот Ada, не смотря на "разработку коммитетом", оказался вполне себе успешным экспериментом по созданию языка для массовой промышленной разработке софта для систем с высокими требованиями к качеству, надежности и ресурсоемкости. Нужен ли этот язык сейчас? И если нужен где-то, то многими ли он будет востребован? Это уже совсем другие вопросы. Но подходить к оценке Ada с точки зрения наличия в нем лямбда-функций и алгоритмов map/filter... Ну это как рассматривать возможность использования карьерных самосвалов в гонках Formula-1. И это если оставаться в рамках цензурной лексики ;)

[life] Странные ощущения по ходу чтения книги "Стив Джобс. Уроки лидерства"

Читаю книгу Джея Эллиота "Стив Джобс. Уроки лидерства". Прочел уже одну треть. Не могу отделаться от нескольких очень странных ощущений.

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

Странность лично для меня здесь вот в чем: я не застал того переворота, который совершили Apple I, Apple II, Lisa и Macintosh. В середине 90-х Apple была сдувающейся компанией, со славным прошлым, унылым настоящим и непонятным будущим. А то, что стало появляться после возвращения Джобса в Apple (iMac, MacBook, iPod, iPhone, iPad) лично мне чем-то выдающимся не казалось. Уж не знаю почему. Может быть потому, что любые компьютерные устройства воспринимались и воспринимаются мной просто как инструменты. Ну в точности как молотки и стамески для столяра. Понятное дело, что какой-то молоток лежит в руке лучше, какой-то хуже. Какой-то удобнее, какой-то долговечнее. Но, в любом случае это расходный материал. И вряд ли кому-то придет в голову сравнивать молоток с произведением искусства, революционным прорывом и переворотом.

И вот когда не считаешь продукцию Apple чем-то выдающимся, то при чтении хвалебных од в адрес Джобса возникает невольное недоумение: а откуда весь пафос?

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