вторник, 24 октября 2023 г.

[prog.c++] Оказывается, std::enable_shared_from_this можно применять и с неполным типом

Увидел неожиданное для себя в статье "On detecting improper use of std::enable_shared_from_this":

#include <memory>

struct D;

struct B : std::enable_shared_from_this<D>
{
};

struct D : B
{
};

int main() {
    auto p = std::make_shared<D>();
    auto q = p->shared_from_this();
}

И это спокойно компилируется.

Другими словами, std::enable_shared_from_this можно использовать и для типов, которые не были еще полностью определены.

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

понедельник, 23 октября 2023 г.

[prog.flame.c++] Ведь ни один вменяемый человек не начнет писать на C++ что-нибудь новое...

Недавно на LOR-е встретил заявление "Ни один вменяемый человек на крестах писать что-то новое не будет..." от патологического хейтера C++. На что смел сказать, что за последние три года дважды довелось поработать с заказчиками, которым потребовалась разработка новых программ именно на C++.

Но не стал озвучивать причины, по которым, заказчики сделали именно такой выбор. За что заслужил пару-тройку комментариев из категории "без доказательств нещитово!"

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

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

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

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

Позволю себе добавить пару важных факторов, которые хейтеры и ниасиляторы C++, почему-то упускают из вида, заявляя, что в современном мире для C++ места не осталось.

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

При этом вы ничего не теряете ни в эффективности, ни в гибкости. Так что, реально, если вам нужен софт, который плотно завязан на что-то вроде FFMPEG, и вы в своем софте будете делать что-то нетривиальное, требовательное к ресурсам, то C++ может оказаться значительно выгоднее, чем какой-нибудь Python с биндингами.

Во-вторых, страшилки про то, что выбрав С++ вы автоматически попадаете на постоянные segmentation fault и бесконечные утечки памяти, как мне кажется, не актуальны уже лет 20. Ну, если и не 20, то лет 10 точно. И причина не столько в том, что C++ за это время стал лучше и безопаснее. Как раз таки не стал (подвижки есть, но они не кардинальные). Но С++ оброс инструментарием, который позволяет минимизировать усилия на борьбу с подобными явлениями: санитайзеры, статические и динамические анализаторы. Так что и падения, и утечки памяти в C++ном коде все еще встречаются. Однако и происходит это гораздо реже, и обнаруживается уже гораздо проще.

Добавлю сюда еще и то, что в последние 20 лет шел постоянный отток разработчиков из C++ в другие языки программирования: сперва это была Java, затем C#, затем Go и сейчас вот Rust. И у этого оттока, помимо негативной составляющей, была и позитивная: большое количество криворуких программистов, которых в принципе нельзя было до C++ допускать, из C++ наконец-то ушло. Поэтому, в среднем, сейчас на C++ программируют по большей части именно те, кто понимает как нужно это делать, чтобы не было мучительно больно.

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

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

Сам я не знаю, насколько это соответствовало действительности тогда и актуально ли это сейчас, но вот человек, который распоряжался деньгами на новый проект, придерживался такого мнения. И, полагаю, имел на это основания.

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


PS. Поскольку все, что может быть истолковано неправильно, будет истолковано неправильно, сделаю оговорку: для C++ осталось мало ниш, где его использование оправдано. И сейчас C++ занимает именно то место, которое он и должен был бы занимать всегда: язык для задач, в которых сложность сочетается с высокими требованиями к производительности и/или ресурсоемкости. Этих задач немного. Но если вы с такой столкнулись, то C++ будет вполне себе оправданным и вполне себе безопасным выбором для нового проекта.

пятница, 20 октября 2023 г.

[prog.memories] Вспомнил кайф от работы над библиотекой timertt

Благодаря вот этой теме на Reddit-е вспомнилась работа над библиотекой timertt, которая у нас в SObjectizer-е применяется для обслуживания таймеров.

Кстати говоря, если кому-то интересно какие есть подходы к обслуживанию таймеров, то краткую выжимку можно посмотреть вот в этом небольшом блог-посте, который ссылается вот на эту основополагающую PDF-у (ее URL, на всякий случай: http://www.cs.columbia.edu/~nahum/w6998/papers/sosp87-timing-wheels.pdf, именно http://, а не https://).

Дело было в конце августа 2014-го года. Тогда SObjectizer еще использовал ACE в качестве базовой библиотеки. Но вот как раз к этому времени единственное, что нам нужно было из ACE -- это таймеры. Которые, как мне помнится, в ACE были сделаны весьма круто (все таки ACE, как инструмент, был отличной штукой, хоть и очень уж в стиле 1990-х). Но несмотря на крутизну и удобство ACE-овских таймеров от такой тяжелой зависимости, как ACE, очень хотелось избавится. Поэтому нужно было сделать свои таймеры.

Так, в общем-то, библиотека timertt и появилась.

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

Да, так вот к чему это все вспомнилось.

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

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

И, что совсем уж удивительно, timertt работает себе и работает. Уже девять лет.

Последние ломающие совместимость модификации вносились шесть лет назад, как раз в октябре 2017-го. А с декабря 2019-го туда вообще ничего не добавлялось, просто нужды не было. Тупо справляется timertt со своей работой, потребности закрывает и все.

Из чего-то подобного еще вспоминается разработка PEG-парсера для RESTinio в 2019-ом. Тогда тоже был кайф от проделываемой работы, хотя шло все гораздо сложнее, чем с timertt. Но кайф от работы ощущался все равно.

Эх... Были времена... Приятно вспомнить.

Зачем был написан этот пост? Наверное, просто для того, чтобы не забывать, какое удовольствие может приносить любимая работа.

PS. Во время подготовки этого поста перечитал собственную же статью на Хабре про easy_parser из RESTinio и офигел от сложности того, что там описано. Как будто совсем другой человек и тот код писал, и ту статью. Какая-то более лучшая версия меня 🙂

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

[prog] В склерозник: отличное чтиво на тему бенчмарков и маркетинга...

...вот эта вот статья: "How fast is ASP.NET Core?"

Уж не помню где ссылка на нее мне попалась на глаза, но прочитал с большим интересом и удовольствием. Даже не смотря на то, она про .NET.

Очень напомнило как мой коллега лет шесть назад принимал участие с RESTinio в подобных соревнованиях объявленных Mail.ru. Особенно когда выяснилось, что лучшие результаты показывают решения, использующие хардкорный busy waiting loop на системных вызовах.

[prog.c++] Послесловие к релизу SObjectizer-5.8.1

Несколько дней назад были зафиксированы версии SObjectizer-5.8.1 и so5extra-1.6.1. Сегодня были сделаны анонсы на нескольких профильных форумах и на Хабре была опубликована статья, рассказывающая о нововведениях. Так что всех интересующихся адресую к этой статье.

У меня же два главных впечатления от работы над версией 5.8.1 таковы:

  • проектирование и реализация bind_transformer заняли буквально несколько часов. А вот покрытие реализации тестами, да так, чтобы эти тесты не роняли компилятор в internal compiler error и не компилировались по 5 минут... Вот на это ушло в разы больше времени.

    Вообще, тесты для bind_transformer -- это отдельная песТня с шаблонной магией (например, раз и два). У меня было даже желание описать все эту магию отдельным постом (или статьей), но прикинув приблизительный объем как-то взгрустнул и не решился 😔

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

    Такая вот наглядная разница между "просто сделать" или "сделать хорошо".

  • Фичу с so_this_agent_disp_binder пришлось реально ждать три года. Прям как в народной мудрости "обещанного три года ждут". Правда, мы и не обещали. Просто вовремя вспомнили, что такая хотелка была 🙂

    А почему вспомнили? А потому, что записано все было "в книжечке". Т.е. в виде issue на GitHub-е.

    Отсюда мораль: хотелки надо фиксировать. Очень желательно в виде issue. Тогда будет хоть какой-то шанс, что хотелка получит воплощение.

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

Ну и да, SObjectizer на GitHub-е тихой сапой перебрался через рубеж в 400 звезд. Оно, конечно, на хлеб не намазывается, но таки чем больше звезд, тем больше доверие потенциальных пользователей. Так что отрадно. Того и гляди, такими темпами через 5 лет и до 1000 дойдем 😉

понедельник, 16 октября 2023 г.

[prog.c++.kill-them-all] Во что обходится это дерьмо, CMake?

Сегодня наткнулся на блог пост "The road to hell is paved with good intentions and C++ modules", создателя Meason-а. А в этом блог посте ссылку на вот эту презентацию: "A new CMake Scripting Language?". Из которой можно узнать интересные цифры. Например, перевод некого проекта Trilinos с GNU Autotools на CMake обошелся Sandia National Laboratories (SNL) более чем в миллион долларов -- около $500K составила стоимость рабочего времени сотрудников SNL и еще около $700K было потрачено на контракты с Kitware по доработкам CMake/CTest/CDash.

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

Но вот после знакомства с вышеупомянутой презентацией я вообще в шоке.

Это как же у Kitware получилось сперва выкатить откровенное дерьмо в мир, затем убедить кучу народа это жрать не просто причмокивая, а еще и доплачивая Kitware?

Снимаю шляпу.

Пару лет назад я был готов добавить в RESTinio поддержку HTTP-клиента за $3.5K (что на тот момент не превышало одной месячной ЗП C++ разработчика моего уровня, причем просто чистой ЗП, без налогов на ФОТ и прочих издержек). А тут создатели CMake не стесняются озвучивать сумму в миллион долларов для того, чтобы сделать улучшенный CMake.

И ведь, скорее всего, найдут и профинансируют. Чтобы на выходе получилось не пойми что. А я не верю в способность разработчиков CMake сделать что-то хорошее. Если бы у них такая способность была, они бы давно бы уже убили себя апстену.


Отдельно мне доставила фраза со слайда #11 в упомянутой презентации:

The book “Professional CMake” largely solves the CMake Documentation problem.

Вот нет! Эта книга, возможно, как-то решает вопрос получения денег с пользователей CMake. Но не решает проблему качества CMake-овской документации.


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


Говорил раньше и повторю еще раз: если собрать список причин по которым стоило бы распрощаться с C++, то CMake там был бы на одном из первых мест.

И не потому, что CMake плохой. Плохого софта не так уж и мало.

А потому, что сообщество, в котором такое дерьмо, как CMake, стало де-факто стандартом, не ждет ничего хорошего. И такое сообщество заслуживает того, чтобы скончаться в муках. Медленно и мучительно.

четверг, 5 октября 2023 г.

[prog.c++.sobjectizer] Марко Арена начал публиковать серию постов "SObjectizer Tales"

Один из пользователей SObjectizer-а, Марко Арена, начал публиковать серию статей под названием "SObjectizer Tales". Это не очередное руководство о том, как программировать с помощью SObjectizer-а. Это рассказ о том, как человек увидел SObjectizer, что полезного в нем нашел и как он решал стоящие перед ним задачи с помощью нашего инструмента.

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

Содержимое серии на текущий момент:


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

Мне сложно выразить собственные эмоции по этому поводу. Пожалуй, для понимания лучше всего привести вот эту цитату из "Законов Паркинсона":

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

Вот точно все про меня: не имея талантов, не отличаясь ничем, кроме способностей и здравого смысла...

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

Прошу простить мне минуту самолюбования, но да, есть теплое чувство внутри.