[prog.c++] My view of the near (and not so) future of the RESTinio project

Now, after the official release of RESTinio-0.6.9, it's a good time to share some thoughts about the near (and not only near) future of the RESTinio project.

It is worth noting that the text below is only my point of view. This point of view can change over time.

This text is split into two parts. The first part tells about rather practical things that I want to see in the upcoming releases of RESTinio. The second part is more philosophical and intended for the discussion about the role of RESTinio in the modern C++ landscape.

Part One. What I want to have in RESTinio 0.6 and what could be seen in 0.7?

[prog.thoughts] Какой способ информирования об ошибках мне бы хотелось иметь для написания надежного кода?

Много лет занимаюсь разработкой софта, который должен работать в режиме 24/7 и, зачастую, под приличной нагрузкой. Это не mission-critical софт, скорее business-critical. Т.е. если будет глючить и падать, то никто не умрет. Так что писать "пуленепробиваемый" и "не убиваемый" кода пока не приходилось. Тем не менее, нестабильная работа написанного нами софта -- это авралы, стрессы, неприятности с клиентами. Понятное дело, что никому такое не нужно.

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

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

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

[life.cinema] Очередной кинообзор (2020/07)

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

Фильмы

Офицер и шпион (J'accuse, 2019). Мне понравилось, посмотрел с удовольствием.

Грейхаунд (Grayhound, 2020). Добротно рассказанная история, за которой интересно следить. И хорошо показанные персонажи, которым сопереживаешь. Слегка разочаровала, разве что, графика. Слишком уж нарисованными выглядели некоторые сцены.

Форпост (The Outpost, 2020). На мой взгляд весьма достойный военный фильм.

Гори, гори ясно (Brightburn, 2019). В принципе, идея мне понравилась. Вот что было бы, если бы Супермен оказался бы плохишом. Но подвело то, что в фильме всего одна звездная актриса, Элизабет Бэнкс, однако, главным-то героем должна была бы быть не она. Так что оттягивание внимания от пацана с суперспособностями на единственную звезду сделало фильм менее интересным, чем он мог бы быть.

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

Всегда верен (Semper Fi, 2019). Купился на хороший трейлер и ожидал напряженный и динамичный фильм про побег из тюрьмы. Но оказалось, что того самого побега в фильме всего 1/5 часть времени. В лучшем случае. Все остальное что-то вроде мелодрамы. В общем, вполне можно и не смотреть.

Призраки войны (Ghosts of War, 2020). Начинался как заштатный фильм ужасов на тему призраков в антураже Второй Мировой. Ближе к финалу авторы замутили твист. Который, как мне показалось, на пользу совсем не пошел. И уж лучше бы фильм оставался заштатным фильмом ужасов на тему призраков в антураже Второй Мировой.

Мой создатель (Archive, 2020). Ну очень нудное кино. Ну очень нудное. Ну очень. Насколько нудное и усыпляющее, что даже финальный твист вызывает скорее раздражение, нежели удивление.

Бессмертная гвардия (The Old Guard, 2020). Редкая бредятина по отдаленным мотивам "Горца". С кучей соплей и чрезмерной толерастией, из-за чего сопли временами оказываются даже не розовыми, а голубыми.

Сериалы

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

Голова (The Head), первый сезон. Посмотреть можно. Но развязка оказалась несколько предсказуемой.

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

[prog.c++] Пример использования шаблонов для создания C-шных коллбэков из методов C++-ных классов

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

Итак, есть известная чисто-С-шная библиотека http_parser, которую много кто использует (в том числе и мы в RESTinio). Для работы с ней нужно создать у себя в программе экземпляр типа http_parser и экземпляр типа http_parser_settings. Где http_parser_settings должен содержать набор указателей на С-шные коллбэки, которые будут вызываться во время парсинга HTTP-сообщений.

Возникла задача сделать так, чтобы коллбэками для http_parser выступали нестатические методы C++ ного класса.

Решалась эта задача в два этапа.

[prog.c++] В склерозник: интересная серия статей про распознавание типа указателя на функцию посредством шаблонов

Утащу к себе в склерозник, дабы затем проще искать было:

• Deconstructing function pointers in a C++ template
• Deconstructing function pointers in a C++ template, the noexcept complication
• Deconstructing function pointers in a C++ template, vexing variadics
• Deconstructing function pointers in a C++ template, the calling convention conundrum
• Deconstructing function pointers in a C++ template, trying to address the calling convention conundrum
• Deconstructing function pointers in a C++ template, addressing the calling convention conundrum
• Deconstructing function pointers in a C++ template, returning to enable_if

[prog.c++] Продолжение истории про parent/child и удаление child-а из метода самого child-а

Около месяца назад в блоге была заметка, в которой показывалась схема с классами parent и child. Класс parent владел экземпляром child, а child в своем методе мог вызвать у parent-а метод replace_child, во время которого текущий child уничтожался. Т.е. получалось, что объект, метод которого сейчас работает, уничтожается прямо внутри этого работающего сейчас метода.

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

Все-таки вот такое:

void child::some_method() {    ... // Some actions.    delete this; // The last action of the method. }

можно контролировать лишь в самых тривиальных случаях. А по мере того, как some_method усложняется и/или погружается куда-то ниже в стек вызовов, вероятность возникновения use after free стремительно приближается к единице. И можно быть уверенным, что в один прекрасный момент use after free таки произойдет.

Под катом небольшой рассказ о схеме, которая была применена для того, чтобы сохранить режим взаимодействия parent и child, но при этом защититься от use after free.

[prog.flame] Может уже и пришло время закапывать C++, но пока он позволяет в коде выписывать ABNF грамматики...

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

Иногда складывается впечатление, что эти стенания повсюду. Особенно на профильных ресурсах, типа Reddit, LOR, RSDN (может и на Хабре, но до Хабра сейчас просто уже руки не доходят).

Финальным гвоздем стали очередные вбросы в Telegram канале C++ Russia от известного своим праздным звездежом хаскелиста Александра Гранина, у которого, походу, второй натурой стал троллинг C++а и C++ников. С традиционным уже участием на C++ Russia с докладом про функциональщину.

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

В тоже самое время этот самый современный C++, в который, как искренне верят неасиляторы, напихали всякой ненужной чуйни, лично мне позволяет в декларативном виде записывать в коде ABNF грамматики из RFC по HTTP/1.1.

Причем это даже не самый еще современный C++, а всего лишь C++14.

И что-то мне подсказывает, что сделать подобное на каких-то "типа альтернативах" C++ будет не так уж и просто. Особенно с учетом накладных расходов в run-time. Если вообще возможно.

Ну а вот и сам упомянутый фрагмент. Который отвечает за парсинг содержимого HTTP-заголовка Transfer-Encoding согласно спецификации.