[prog.sadness] Чем больше шуму вокруг C++20 тем больше хочется уйти с C++ вообще

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

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

Может быть потому, что не хочется в очередной раз проходить путь адаптации кардинальных изменений в новом стандарте. Я уже через это прошел когда появился C++98, а потом и C++11. Оба раза это занимало годы и годы оглядываний на старые компиляторы, в которых стандартом либо еще не пахнет, либо же он реализован частично. Даже сейчас еще бывают случаи, когда приходится пользоваться компилятором с неполной поддержкой C++11... Так что впереди еще лет десять привыкания к C++20.

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

Может быть потому, что языку 35 лет, новые стандарты начали штамповать каждые три года, а важные принципиальные разногласия в C++ сообществе так и не устранены. Например, исключения и RTTI часто оказываются под запретом, а сама стандартная библиотека языка вряд ли сможет работать с полностью отключенными исключениями. Или без возможности использовать динамическую память.

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

class Demo {
  [[nodiscard]] bool empty() const noexcept;
  ...
};

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

Может быть это старческая боязнь перемен...

А скорее всего все это в совокупности.

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

Но все равно есть какое-то подсознательно-неосознанное ощущение "а не пора ли свалить с этого перегруженного корабля, у которого на мостике творится одно, в машинном отделение -- другое, а в трюме все вообще по-другому?"

[life.cinema] Как бы я попробовал бы сделать продолжение Терминатор-2

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

Итак, идея в том, что в рамках рассказанной в первых двух фильмах истории Skynet отправил в прошлое не двух T-800, а трех. Второго из них уничтожили в первом "Терминаторе", третий стал главным героем "Терминатор-2". А вот первый был отправлен Skynet-ом в прошлое еще раньше, еще до действий первого фильма. Его задачей было отследить происхождение Джона Коннора.

Нас же не удивляет, что в первом фильме терминатор из будущего прибыл именно в Лос-Анджелес и не удивляет, что он начал разыскивать Сару Коннор, хотя точно не знал какую именно. Но откуда у Skynet-а появилась информация о Саре Коннор из Лос-Анджелеса?

[prog.c++] Пришли вести об окончании формирования C++20, только вот...

...почему-то вспоминается старое проклятие: "Да шоб ты жил в эпоху перемен!"

Возможно, на мне сейчас сказывается усталость после нескольких непростых рабочих недель, но грядущее пришествие C++20 я воспринимаю как непростую историю с Python2 и Python3. В этом посте постараюсь объяснить почему у меня такое ощущение.

Мне думается, что только вот сейчас, к 2020-ому году в большинстве своем состоялся уход от C++98/03 к C++11/14/17. Т.е., несмотря на то, что где-то еще живут большие кодовые базы на C++98, все-таки нормой становится современный C++. И это хорошо.

Хотя еще много мест, где современный C++ -- это в лучшем случае C++11 на уровне gcc-4.8.

И поэтому даже сегодня, в 2020-ом году, при разработке C++кода, которому грозит либо применение на широком спектре компиляторов, либо же который разрабатывается под специфические нужды конкретного заказчика, то и дело приходится ограничиваться C++11... Если честно, я на этом фоне даже думаю, что в прошлом году сильно ошибся, переписав SObjectizer-5.6 сразу на C++17, а не на C++11 (ну или хотя бы на C++14).

И вот что тут важно: в принципе, даже проект, который был написан на C++17, при необходимости можно переделать под C++14 или С++11. Понятно, что делать это неприятно, но если за это платят, то почему бы и нет.

Механика такого даунгрейда так же понятна и уже неоднократно проходилась. Вещи типа [[nodiscard]] или [[fallthrough]] помещаются под макросы, фишки типа constexpr if или structured binding не используются, fold expression разворачиваются вручную... Да, объем работы увеличивается. Но все-таки он не превышает некоторого психологически-приемлемого уровня.

Но C++20 вносит в язык несколько принципиально новых возможностей. Навскидку: модули, концепты, короутины и гораздо более продвинутый constexpr. Как отказаться от их использования так, чтобы разработанный код можно было использовать и в C++11, и в C++20, я не представляю.

А это означает, что C++20 вводит еще более строгий и жесткий "водораздел" между старым и новым кодом, чем это было даже после появления C++11. Т.е., если код начал писаться под C++20, то только под C++20 его и можно будет использовать. И простого даунгрейда написанного под C++20 кода под старые C++ стандарты (пусть даже старым будет C++17) уже не будет.

Для разработчиков прикладного кода на C++ это вряд ли будет представлять проблему. А вот для разработчиков библиотек, вроде нас, это будет проблема. Ведь если портировать библиотеку под C++20, то ее не смогут использовать те, кто вынужден оставаться на C++11/14/17. А таких в ближайшие 4-5 лет, а то и больше, будет большинство.

Что, как мне кажется, для библиотеко-писателей означает одно: если хочешь, чтобы твоя библиотека использовалась широко, то сиди на C++11 и не рыпайся. До C++32. Потом можно будет на C++20 перебраться.

PS. Сам в последнее время для одного из клиентов вынужден оставаться в рамках C++11. И не смотря на то, что между C++14 и C++11 изменений не так уж и много, мне кажется, что даже по сравнению с C++14 одиннадцатые плюсы уже неюзабельны :(