[life.cinema] Очередной кинообзор (2019/09-2019/10)

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

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

Кокаиновый барон (Running with the Devil, 2019). Фильм средненький и в нем, на мой взгляд, слишком много разных персонажей с совсем небольшими ролями. Но, как мне показалось, отлично передает ощущение того, что единственная вещь, которая ждет любого, кто связывается с наркотиками -- это смерть.

В тени луны (In the Shadow of the Moon, 2019). Неоднозначные впечатления. Вроде бы пока смотришь, то интересно и хочется узнать, что будет дальше. Но когда фильм заканчивается и пытаешься задуматься о том, а как все это в принципе возможно и почему так, а не вот так, то возникает ощущение "ну фигня же какая-то". Впрочем, это ощущение характерно практически для всех фильмах о путешествии во времени и временных петлях.

Падение ангела (Angel Has Fallen, 2019). В принципе, вполне в духе предыдущих фильмов этой серии. Но лично мне экшена было недостаточно, да и интриги никакой не оказалось, со злодеями все сразу стало понятно.

Рэмбо: последняя кровь (Rambo: Last Blood, 2019). Халтурно, как мне показалось. Сперва час и пятнадцать минут скучной мелодрамы, затем десять минут не очень внятно показанного экшена, потом еще пять минут соплей. В общем, фильм, который можно было бы и не снимать, и не смотреть.

Человек-паук: вдали от дома (Spider-Man: Far from Home, 2019). В приниципе, красочный и яркий фильм и вполне себе достойное продолжение супергеройской вселенной Marvel... Но очень уж он детский, т.е. детям младшего школьного возраста, наверное, посмотреть можно, а вот для их родителей там не будет ничего интересного.

Гемини (Gemini Man, 2019). Мне не понравился. Есть ощущение, что фильм предназначен для аудитории возрастом 10-12 лет, поэтому детям, может быть, и зайдет. Мне не зашел.

К звездам (Ad Astra, 2019). Как по мне, так скучная, нудная и слишком затянутая муть.

---

В общем, из достойного разве что "Оперативник" и "Кокаиновый барон".

На "Джокера" не выбрался, буду ждать пока на ivi или megogo в хорошем качестве завезут. По поводу очередного продолжения "Терминатора" еще не определился. В общем-то, идти не хочется, дабы не разочаровываться в очередной раз.

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

[prog.flame] Ну как же плохо, что комитет по стандартизации C++ работает как "бешеный принтер"

Одна из претензий к современному C++ состоит в том, что начиная с C++11 язык слишком быстро развивается и в него завозят слишком много ненужного. Один одиозный персонаж на LOR-е даже специальный термин для этого употребляет: мол, комитет печатает стандарты как бешеный принтер. Свежий топик на эту тему на LOR-е вместе в этим самым одиозным персонажем можно найти здесь.

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

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

class params_with_value_producer_t    :  public producer_tag< parameter_with_mandatory_value_container_t > {    using actual_producer_t = std::decay_t<          decltype(params_with_value_producer_details::make_parser()) >;    actual_producer_t m_producer{          params_with_value_producer_details::make_parser() }; public :    params_with_value_producer_t() = default;    RESTINIO_NODISCARD    auto    try_parse( source_t & from )    {       return m_producer.try_parse( from );    } };

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

Но в C++14 с этим нет никаких проблем. Посредством decltype можно узнать тип этого объекта. И объявить внутри класса объект данного типа.

Предлагаю вдуматься в это: современный C++ позволяет внутри нешаблонного класса объявить атрибут некоторого неизвестного автору класса типа.

Причем тип реально неизвестный, он формируется компилятором автоматически на основании довольно сложной конструкции. Впрочем, это проще показать, чем рассказать. Вот, собственно, та самая make_parser:

auto make_parser() {    return produce< parameter_with_mandatory_value_container_t >(          repeat( 0, N,             produce< parameter_with_mandatory_value_t >(                ows(),                symbol(';'),                ows(),                token_producer() >> to_lower()                      >> &parameter_with_mandatory_value_t::first,                symbol('='),                alternatives(                   token_producer()                         >> &parameter_with_mandatory_value_t::second,                   quoted_string_producer()                         >> &parameter_with_mandatory_value_t::second                )             ) >> to_container()          )       ); }

Причем в качестве типа возвращаемого значения для make_parser не зря указывается auto. Как раз этот auto позволяет возвратить наружу "то, не знаю что". В буквальном смысле. Поскольку тип возвращаемого из make_parser значения зависит от типов параметров, переданных в produce, а сами эти параметры так же являются результатом вызова других шаблонных функций и т.д., и т.п.

А еще auto можно обнаружить в качестве типа возвращаемого значения метода params_with_value_producer_t::try_parse. Тут получается вообще смешно: класс params_with_value_producer_t содержит объект неизвестного типа, а метод try_parse этого класса возвращает что-то, что производит тот самый объект неизвестного типа. Т.е. можно хранить неизвестно что и возвращать незнамо что. И это в статически типизированном языке!

Короче говоря, то, что в C++14 делается элементарно, даже в C++11 вызывало бы затруднения и вряд ли было бы возможно в C++98/03. И все это можно использовать здесь и сейчас. Очень так неслабо упрощая жизнь самому себе и экономя собственное время (которое, как известно, никак не вернуть).

И это речь шла только о C++14. А ведь C++17 делает жизнь разработчика еще проще (вот недавний пример на тему).

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

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

Для желающих узнать, что же там за такой хитрый тип генерируется компилятором, под катом его определение, вырезанное из выхлопа компилятора:

[prog.c++] Эволюция средств поддержки загрузки файлов на сервер в RESTinio

Некоторое время назад я в блоге показывал фрагменты экспериментов с парсером значений HTTP-полей в RESTinio (вот, например, последний из этих постов на данный момент). Все это было нужно не само по себе, а как часть более общей задачи. В частности, как часть предоставления пользователям RESTinio простого механизма обработки загружаемых на сервер файлов (т.н. file uploading). Ниже приведены примеры того, с чего поддержка file upload начиналась месяц назад и к чему удалось прийти на данный момент. Кому интересно, милости прошу под кат.

[prog.c++] A follow-up for basiliscos's article "Request Response Message Exchange Pattern"

Ivan Baidakou, the author of rotor actor framework for C++, wrote a blog post with a comparison of request-reply pattern support in different C++ actor frameworks: "Request Response Message Exchange Pattern". I've found the reference to that article on Reddit and started to write a comment but decided to write my own blog post because the answer started to grow rapidly.