О блоге

Более двадцати лет я занимался разработкой ПО, в основном как программист и тим-лид, а в 2012-2014гг как руководитель департамента разработки и внедрения ПО в компании Интервэйл (подробнее на LinkedIn). В настоящее время занимаюсь развитием компании по разработке ПО stiffstream, в которой являюсь одним из соучредителей. Поэтому в моем блоге много заметок о работе, в частности о программировании и компьютерах, а так же об управлении.

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

[life.photo] Характерный портрет: вы и ваш мир моими глазами. Безвозмездно :)

Вы художник? Бармен или музыкант? Или, может быть, коллекционер? Плотник или столяр? Кузнец или слесарь? Владеете маленьким магазинчиком или управляете большим производством? Реставрируете старинные часы или просто починяете примус? Всю жизнь занимаетесь своим любимым делом и хотели бы иметь фото на память?

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

[prog.c++] Местами C++ недостаточно многословен для меня

С++ многими рассматривается как многословный язык. И хотя само по себе понятие "многословный" весьма субъективно, но если сравнить C++ с более молодыми конкурентами, вроде Rust или Go, но некая многословность таки заметна невооруженным взглядом: всякие template, typename, virtual, override, noexcept и т.д., и т.п.

У меня отношение к многословности C++ специфическое: да, она имеет место быть и на небольших фрагментах кода она может раздражать. Однако, когда приходится целый день копаться в простынях незнакомого кода, то все эти бросающиеся в глаза template, typename, virtual, override, noexcept и пр. начинают восприниматься как благо: хоть какие-то проблесковые огоньки в сплошном потоке.

А давеча столкнулся с ситуацией, в которой C++ мне показался недостаточно многословным.

Обнаружил в коде, написанном больше года назад, классическую для C++ ошибку: повисшую ссылку. Лямбда захватывала ссылку на объект, который жил внутри контейнера. В качестве контейнера был std::vector и, естественно, когда что-то из контейнера удалялось, то захваченная ссылка оказывалась невалидной.

Как это все проработало столько времени и не попалось на глаза раньше совершенно непонятно, ну да не в этом суть.

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

И вот тут-то встал вопрос: а как по коду быстро и точно разыскать все лямбды?

Вот было бы в C++ ключевое слово lambda для определения лямбда-функции, было бы проще.

Но такого ключевого слова нет.

Жаль, как по мне. Будь такое ключевое слово (или какой-то специальный символ, скажем @), то код на современном C++, в котором, местами, лямбда на лямбде и лямбдой погоняет, читался бы проще. ИМХО, конечно же.

---

Есть ли у этого потока сознания какой-то сухой остаток? Вряд ли.

Разве что кто-то хочет создать современную замену C++ (ну не ограничиваться же Circle, Carbon, Val и cppfront, в самом-то деле) и задумается стоит делать эту самую замену настолько же лаконичной, как вышеупомянутый Rust?

[memories:prog,work,life] Фотография шестилетней давности...

Facebook любезно напомнил фотографию из января 2017-го года:

Это самое начало проекта RESTinio, я даже не уверен, что у нас уже к тому времени было само название RESTinio.

На снимке мой коллега и основной разработчик RESTinio, Николай Гродзицкий, фиксирует на доске свои идеи о том, как RESTinio будет устроена.

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

Сам офис уже обжит. А за три месяца до этого было вот так:

---

Не знаю, что еще добавить. Разве что банальное: как же быстро летит время.

Но радует то, что все еще живы, все еще работаем. Сейчас тот же RESTinio пока вынуженно поставлен на паузу, но времена нынче непредсказуемые, невозможно предугадать куда все развернется. Так что поживем, увидим. Надеюсь, сможем сделать очередной релиз SObjectizer, а там и до RESTinio руки дойдут.

[prog.flame] И долго в Boost будут тащить все, что не попадя?

На включение в Boost претендует библиотека Aedis, ревью идет прямо сейчас. Aedis -- это написанный на Asio клиент для Redis-а.

Определенно нужная для кого-то вещь, спору нет. Автору библиотеки респект и уважуха на полном серьезе. Так что у меня нет никаких сомнений о нужности Aedis-а вообще.

Зато есть вопрос "А что сейчас есть Boost и зачем он нужен?"

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

Но клиент для Redis-а?

Его что, кто-то хочет видеть в стандартной библиотеке C++? Серьезно?

А раз нет, то какой смысл развивать Boost как сборище всякого разного и разнообразного? Зачем весь этот винегрет держать под одной крышей?

Простите мне мой цинизм, но я вижу в этом всего лишь одну цель: паразитирование на известности Boost-а.

Вот жила-была себе библиотека, мало кто про нее знал. А тут она раз, и в Boost-е. И, поскольку множество C++ников выросло на принципе "если что-то нужно, то посмотри сперва в Boost", то как раз такие C++ники посмотрят сперва в Boost, возьмут оттуда первую попавшуюся и не будут больше ничего искать.

Boost уже сейчас скопище из более сотни (если не ошибаюсь) библиотек. Причем даже с некоторым дублированием (сколько там сейчас библиотек для работы с конечными автоматами? сколько для парсинга?). Сам по себе вопрос "А вы знаете Boost?", который был актуальным году в 2005-ом, сейчас уже потерял смысл. А человека, который ответит на него "Да" мне будет сложно воспринимать всерьез.

Может быть включение в Boost гарантирует то, что авторов библиотек будут финансировать? Или есть гарантия, что библиотеку автоматически подхватят, когда первоначальный автор перестанет ей заниматься?

И ладно бы Boost задавал какую-то недостижимую планку качества, а библиотеки оттуда не имели бы никаких вменяемых альтернатив за пределами Boost-а.

Так ведь нет.

Какие-нибудь Catch2 или doctest могут быть намного более простыми и удобными альтернативами Boost.Test. А spdlog может быть удобнее и практичнее, чем Boost.Logging. А fmtlib чем Boost.Format.

Т.е. жизнь показала, что и вне Boost-а можно создавать отличного качества библиотеки, которые будут востребованы больше, чем аналоги из Boost-а.

А еще жизнь показала, что C++у жизненно важно иметь пакетный менеджер, который позволит легко подключать в проект любые библиотеки. И на мой рабоче-крестьянский взгляд, это сейчас гораздо важнее, чем пытаться собрать кучу всякого-разного под какой-то одной крышей.

Но нет, Boost продолжает вбирать в себя всякую всячину.

---

PS. Из личного: убежден, что если бы Beast не протолкнули бы в Boost, то ее популярность в C++ мире была бы сильно ниже. Впрочем, если кто-то взял в проект Boost.Beast просто потому, что "это же из Boost-а", то что тут остается сказать? Разве что "полной ложкой, говорю, черпай!"

PPS. Не в первый раз поднимаю эту тему. Но что поделаешь, если время идет, а смысла в существовании Boost в его привычном виде я как не видел, так и не вижу.

[prog.wow] Это настолько прекрасно про "маргинальщину", что невозможно не утащить в анналы :)

Найдено на RSDN. Такой сгусток боли невозможно не утащить в склерозник, ибо вряд ли когда-нибудь еще встретится столь мощно сформулированное:

IMHO, упоминание маргинальщины (D, Haskel, Erlang, SVN, FreeBSD) — это диагноз. Разумные люди от нее избавляются и переходят на более популярные инструменты, потому что так удобнее. С маргинальщиной живут только полные фанатики. И параноики, которым постоянно кажется, что D — центр вселенной и оттуда кто-то что-то тырит. Работают такие фанатики исключительно в одиночку. Ни один разумный человек с маргинальщиной работать не будет, даже при зарплате в разы выше рынка.

Комментировать не буду, ибо только портить. Свое отношение к использованию немейнстрима уже высказывал много-много лет назад и принципиально мнения не поменял.

[prog.flame] Знания фреймворков, полезные и бесполезные...

В RSDN-овском сраче (откуда проистекает и предыдущая заметка) высказал несколько вещей, которые на первый взгляд могут выглядеть странно. Может даже сложиться впечатление, что они противоречат друг другу. Попробую раскрыть тему и пояснить что к чему.

---

Итак, вещь первая: при смене фреймворка знания предыдущего фреймворка оказываются бесполезными. Например, опыт в MFC окажется бесполезным при работе с Qt, опыт работы с Qt окажется бесполезным при работе с Asio, опыт с Asio окажется бесполезным при работе с FFMPEG и т.д., и т.п.

Да, столь резкая смена (Qt на Asio и Asio на FFMPEG) запросто возможна при смене предметной области.