...почему-то вспоминается старое проклятие: "Да шоб ты жил в эпоху перемен!"
Возможно, на мне сейчас сказывается усталость после нескольких непростых рабочих недель, но грядущее пришествие 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 одиннадцатые плюсы уже неюзабельны :(
Комментариев нет:
Отправить комментарий