#cplpl_doomed

В С++ есть фича, которая описана не совсем так, как описаны большинство фич С++(с помощью понятия "наблюдаемое поведение"), а с помощью описания трансформации AST. Речь идет про range-based for loop.

Вот преобразование AST: #abi

{
    auto && __range = range-expression ;
    auto __begin = begin_expr ;
    auto __end = end_expr ;
    for ( ; __begin != __end; ++__begin) {
        range-declaration = *__begin;
        loop-statement
    }
}

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

for (auto& v : return_temporary().return_reference_to_temporary_subobject())

Коллеги из комитета по стандартизации сегодня рассказали, что С++ комитет отказался чинить эту фичу, потому что нет общего решения для С++, его надо придумать до C++26, но придумать никто не может.

Теперь и в твитторе: https://twitter.com/NicoJosuttis/status/1443267749854208000?s=19

С++ doomed. С этими старперами из IBM/Google/Microsoft, которые заинтересованы лишь в том, как бы ничего не сломать, у руля, C++ скоро превратится в Cobol.

Лично я об этом не жалею, для души буду писать на Rust, зато безбедная старость и образование для детей обеспечено.

Когда я читаю что-то подобное 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, насколько упрощает жизнь и ускоряет развитие жестко прошитая в язык статическая линковка...

Кстати, кажется, вполне можно воспринимать #carbon именно вот с этой точки зрения, что, наконец-то, какая-то компания взяла, и решила запилить С++ 2.0 на основе clang, все, как я и заказывал.

(а всратый синтаксис от Rust - дань моде и попытка хайпануть)

#cplpl_doomed

Опять я мастер предсказывать уже произошедшие события!

https://www.reddit.com/r/programming/comments/w2thvo/carbon_an_experimental_c_successor_language/

Утащу комментарий с reddit:

"To give some context, in February of 2020 there was a crucial vote in the C++ standard committee about breaking ABI compatibility in favor of performance, mostly pushed by Google employees.
The vote failed. Consequently, many Googlers have stopped participating in the standardization of C++, resigned from their official roles in the committee, and development of clang has considerably slowed down.
Now, they've revealed that they've been working on a successor language to C++. This is really something that should be taken seriously."

https://thephd.dev/finally-embed-in-c23
https://news.ycombinator.com/item?id=32201951

Наверное, только ленивый не рассказал про embed в C, я же хочу сосредоточиться вот на каком аспекте этого события - про комитеты, лоббирование, и почему С/С++ #cplpl_doomed

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

https://news.ycombinator.com/item?id=32202627
https://news.ycombinator.com/item?id=32204481

Там он рассказывает примерно вот про что(прочтите, вдруг я в глаза долблюсь):

* Вы ничего не понимаете, все сложно. Я потратил кучу времени на то, чтобы со всем этим разобраться.

* Есть платформы, на которых даже нет файлов.

* Есть платформы, на которых byte - 32 бита, и это не PDP в музее.

* Наши ошибки могут стоить ажно 1% перфа(тут я хочу напомнить, что недавно из-за ABI комитет по С++ отказался ускорить С++ на 5 - 10%).

И, поэтому, конечно, совершенно нормально, что на мелкую фичу, которая НИКАК с этим не связана:

"Are we're really talking about compiling on such platforms?"

"No, I'm mainly talking about targeting. My point is not so much about embed, but rather that, almost anything you assume you think you know about how computers work isn't necessarily true, because C targets such a wide group of platforms."

потрачено 5 лет.

Ну, то есть, нам рассказывают как все сложно на target, чтобы потом сказать, что 5 лет обсуждали, есть ли понятие "файла для embed" на host платформе, или нет.

Про комитеты, С/C++, и вообще:

* Почет и уважение члена такого сообщества заключается не в том, насколько он упростил жизнь нам с вами, а сколько много сложных и интересных задач он затащил от людей, которые ставят туда задачи(это не мы с вами)

* Если ты разобрался в сложной теме, например, в модели памяти С/C++, то у тебя довольно мало реальных стимулов эту модель упрощать. Если в ней станет легко разобраться - а зачем нужен ты и твой ценный сейчас опыт? А сложных и интересных задач "приделай сюда еще одну заклепку", которые все еще более усложнят - завались.

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

По какому номеру в списке идет упрощение модели памяти и починка range-based-for-loop, вы сами можете дофантазировать.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2739r0.pdf #cplpl_doomed
https://www.opennet.ru/opennews/art.shtml?num=58527

А теперь вот и Страуструп решил высказать свое "фи" по поводу безопасных языков программирования.

И, несмотря на то, что наша аргументация во многом совпадает (а было бы странно иначе, потому что она лежит на поверхности), все равно - Бьерн - старый гондон из группы стандартизации, и этот текст он, наверняка, написал с плохой мотивацией - ему, простите, жалко терять такую классную позицию (автор языка, используемого в mission critical сложных системах!).

А все, а раньше надо было, заниматься развитием языка, а не замораживанием его на месте, по сути, занимаясь, в основном, перделками и свистелками.

#llvmweekly #cplpl_doomed

https://discourse.llvm.org/t/abi-break-in-libc-for-a-17-x-guidance-requested/74483

"The libc++ has informed me that would like to break the libc++ ABI for the next point release of 17.x because of a bad bug in std::expected. See issues here"

Коллеги хотят сломать ABI в libc++.

Не просто так, а чтобы починить баг, в каком-то классе, который раньше был experimental (поэтому баг никто не замечал), а в 17 кленге его вывели в stable.

#abi - зло. Хотя бы потому, что заставляет несколько важных (и занятых) дядек обсуждать эту херню на серьезных щщах.

"Ах, отвести ли нам 17.1, ох, нет, давайте вмержим в 17.0.4"

ABI - одна из многих причин, которая тянет С++ на дно.

Нет чтобы пересобрать приложение, и забыть про этот баг, как про страшный сон.

Если вы прочли этот #rant, то точно знаете, что профили от Страуструпа - это треш, угар, и содомия, потому что:

1) их не существует в природе

2) они не решают задачу memory safety, как ее видит индустрия, а решают какую-то другую задачу.

Но Бьерни сучит ножкой, и требует принятия их в стандарт:

https://www.opennet.ru/opennews/art.shtml?num=62821

#cplpl_doomed , ага.

#llvmweekly #cplpl_doomed

https://discourse.llvm.org/t/factoid-each-class-template-instantiation-costs-1kib/86189

TL;DR - каждый раз, когда вы инстанциируете шаблон, в мире умирает котик, вы тратите 1K памяти, и это очень много, потому что header only библиотеки:

"Maybe what this all points to is that header-only library evolution is a dead end when it comes to compile time, and that if you want to have fast compiles, the old ways, i.e. forward declarations, pimpl patterns, and other forms of implementation hiding, are still relevant if you care about compile time, even in a modular world"

Очень пересекается с цитатой из https://t.iss.one/itpgchannel/22, 100500 раз писал, и буду продолжать писать, что избыточная мономорфизация/inline - зло, не надо бояться virtual method call, pimpl, и вот это вот все.

И это коллега пишет только про время и потребление ресурсов компилятором, и не упоминает того, что избыточно встроенный код еще и медленнее может быть, потому что плохо использует кеши процессора (например, https://t.iss.one/itpgchannel/1547).

UPD: про pimpl вот еще ссылка - https://github.com/llvm/llvm-project/commit/bb1765179e1f, пример того, как сам LLVM у себя выпиливает излишнюю мономорфизацию.