Когда я читаю что-то подобное https://habr.com/ru/post/579490/, меня охватывают два чувства: #abi #cplpl_doomed #cppcom

1) Презрение к тем, кто последние 15 лет занимается развитием С++, потому что их коллективный разум не смог родить ничего похожего на https://doc.rust-lang.org/book/ch19-06-macros.html. На минуточку, constexpr в С++ может посчитать какое-то значение в compile time, когда в нормальных языках можно породить любое AST, не только константу.

2) Чувство беспомощности, потому что я прекрасно осознаю, что не могу сделать ничего, чтобы предотвратить неминуемый закат С++.

Вы вот знаете, как происходит голосование в комитете по стандартизации С++? Насколько я знаю: голосование там идет от компаний, и от стран. От американских компаний, Яндекс там голосовать не может, например. Посчитайте, какой перевес в комитете имеют представительства условного MS + IBM + G + FB.

И что можно сделать, если эти люди решили, что им важнее ABI compatibility с кодом, который собрали еще под Borland C++ под DOS? Вопрос риторический.

Вместо того, чтобы регулярно ломать ABI(не вижу в этом проблем, всегда можно новые версии делать в новом namespace), и избавляться от груза накопленных ошибок, С++ тащит их за собой(just to name a few - locale, iostreams).

(про locale, ABI, и std::format можно почитать тут - https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-help-me-god-please, начиная с "A Brief History of fmt")

Из-за боязни проблем с ABI почти весь современный код С++(и его стандартная библиотека) живет в header-only режиме. Это отдельная, очень больная, тема, потому что скорость разработки складывается из отдельных кирпичиков, и скорость компиляции кода один из них.

BTW, Rust очень правильно делает, что не спешит со стандартизацией. Развивать реализацию гораздо, гораздо проще, чем стандарт. Реализация развивается через pull request на gihub, а не письмами на деревню дедушке.

Короче, к чему это я? Я очень надеюсь, что какая-нибудь реализация С++(например, clang) пошлет стандарт(вместе с дедами, что его пишут) нахер, и начнет развивать С++ сама. А что, Apple(главный стейкхолдер clang) не боится ломать вещи, не боится ломать ABI и backward compatibility, они смогут, при желании. Проблема в том, что желания у них нет, С++ для них это побочный продукт жизнедеятельности clang(который для Apple является компилятором objective-c, в первую очередь, и базой для Swift, во вторую). На gcc и msvc надежды нет, это главные апологеты совместимости с залежалым говном мамонта.

И, BTW, насколько упрощает жизнь и ускоряет развитие жестко прошитая в язык статическая линковка...

https://www.youtube.com/watch?v=u9R4RoaLSIM #abi
https://habr.com/ru/company/yandex/blog/649497/

Я всегда спрашиваю, "а чо там с range-based for loop", и мне не отвечают. Комитет С++ уже много-много лет ищет пуговицу, потому что его взяли в заложники IBM(и другие компании, которым важно поддержание ABI) и несколько старых дедов(которым важно поддержать свое слабеющее влияние), и не дают решать насущные проблемы.

Пуговицу искать, конечно, очень увлекательно, но перспективы С++ сейчас, конечно, очень туманны. #cppcom

https://tjournal.ru/news/533398-rukovoditeli-ibm-vo-vnutrenney-perepiske-nazyvali-rabotnikov-starshe-40-let-dinozavrami-kotorye-dolzhny-vymeret

Новость, конечно, позитивная, потому что это сразу решит проблемы с дедами в Комитете С++, мешающими этот стандарт двигать вперед. Or not? #cppcom

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2723r0.html

Интересный proposal про zero-initialize по умолчанию в C++. #cppcom

TL;DR - оптимизации за последние лет 20 научились справляться с этим, и теперь zero initialize ничего не стоит, а иногда делает код даже быстрее. Удивительный факт, но вот коллеги пишут, что zero-initialize для регистров способен разбивать ложные цепочки данных, и, тем самым, улучшать код с точки зрения out of order execution.

Примут ли его?

Я сомневаюсь, что замшелые деды из стандарта пойдут на такое радикальное изменение.