Comments 23
Проделана огромная работа. Чем больше фич я вижу, тем меньше у меня уверенности в своих знаниях
У меня маленько по другому:
Чем больше фич я вижу, тем меньше у меня уверенности в надежности этого монстра, тем меньше желания с ним связываться.
Умиляют вот такие заявления:
И одна из самых впечатляющих добавленных вещей, новость о которой разлетелась в сообществе
...
Если вкратце, то можно станет писать:
...
с претензией на то что сейчас, все сообщество бросится переписывать мегабайты существующего кода, который и так вполне себе работает. Надо же быть в тренде новомодных веяний по написанию "the range‐based for loop".
Какие дополнительные инструменты вы используете?
Интересно, что по всем инструментам наблюдается небольшое снижение - что бы этот тренд значил?
Допустим, падение использования отладчиков (-6%), санитайзеров (-2%) и статических анализаторов (-2%) можно было бы списать на то, что язык потихоньку становится безопаснее. Но с профайлерами (-6%) и особенно clang format (-4%) вообще непонятно.
Или всё проще, и публика его блога потихоньку сбегает на Rust, продолжая почитывать статьи про C++ из праздного интереса? :)
Регулярно читаю рассылку пропозалов по C++, но смотрю, обновлений за декабрь так и не появилось. Скажите, это каждый год так? Не знаете, сколько ещё ждать?
До 2020 реже публиковали, т.к. публикации были привязаны к оффлайновым встречам комитета. С началом пандемии они перешли на ежемесячные виртуальные созвоны. Возможно всё станет как до 2020, а может и нет, а вообще рекомендую https://github.com/cplusplus/papers тут хотя бы судьбу пропозалов можно поглядеть
Кстати, а можно как-то скачать все пропосалы из их рассылки единым пакетом, желательно вместе с какой-то программой для чтения и поиска? Помнится когда-то раньше у них гугл группа была, я искал как скачать оттуда но ничего не нашел.
https://wg21.link/ там есть нужные ссылки, например распарсить wg21.link/index.json и выкачивать.
Свято верю что концепты и модули когда их распробует комьюнити могут радикально увеличить популярность плюсов.
Концепты резко снижают порог входа в шаблоны - фактически, ключевую фичу плюсов.
Модули фиксят медленную компиляцию и упрощают переиспользование кода за счёт модульной инкапсуляции.
Модули не факт что дадут радикальное ускорение на практике. У кого-то выигрыш на реальном проекте составил 2x, у кого-то получилось +- как было.
Есть измерения, правда, от 2019 г., в которых модули получаются даже медленнее в условиях параллельной компиляции на большом числе ядер: www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1441r1.pdf.
Некоторые утверждают, что якобы в стандарт внесли версию, в которой не учли фидбек от производителей компиляторов.
А с чем связана неоптималность модулей? Если глянуть на их теорию - кажется, они должны очень ощутимый прирост по сравнению с вариантом с инклудами дать. Каждый "хедер" (в ковычках потому что у модулей это не совсем хедер) с ними строго по одному разу обработается
В статье по той ссылке ("Are modules fast?", 2019 г.) у них получилось, что замедление в многопоточных сборках вызвано тем, что одни процессы начинают много простаивать, ожидая других. (Я не исключаю, что частично эту проблему могли побороть за эти годы, или переложить на плечи систем сборки.)
Другая статья, от 2022 г., в тесте из которой на clang получилось, что полные сборки ускоряются модулями на 10-20%, а инкрементальные сборки замедляются вплоть до 22 (!) раз: https://observablehq.com/@vsapsai/effect-of-clang-modules-on-compilation-time. Объяснение у них такое, что при изменениях в популярных хедерах модули заставляют пересобирать большее число исходников.
Третий источник - видео от 2021 г. (https://www.youtube.com/watch?v=9OWGgkuyFV8), в комментарии к которому некто retropaganda (не знаю, насколько авторитетный?) говорит о сложностях с запоминанием и объединением контекстов препроцессора.
С точки зрения логики, модуль собирается по графу, верно? И соответственно если в нём много зависимостей оно просто тупо будет ждать пока освободится достаточное колличество нод для сборки на многопроцессорных системах.
В то время базовые инклюды это тупо копировать в исходник кусок кода. Да это занимает в разы больше машинного времени но это можно распараллить на кучу потоков. И единственный затуп тут может быть с решением екстернов, всё.
Просто рассматривайте модули как те же инклюды, но для которых гарантируется повторяемость результатов включения вне зависимости от контекта. Это значит, что если компилятор уже распарсил подобный инклюд-файл, то больше нет необходимости парсить его повторно, и достаточно взять готовый результат его обработки.
При идеальной реализации скорость компиляции с подобными контексто-независимыми инклюдами будет всегда выше. В реальности же у нас имеются довольно большие накладные расходы на обмен результатами парсинга между нодами.
Главное причина по которой модули в перспективе могут будуть здорово оптимизированы - они локализуют приватные зависимости. При сборке большого количества шаблонного кода это очень важный фактор
Концепты резко снижают порог входа в шаблоны — фактически, ключевую фичу плюсов.
А в чём заключается высокий порог входа в шаблоны? Новичку вовсе не нужны ни SFINAE, ни возможности городить конструкции в стиле Александреску, тем более, что в приличных местах за такое бьют по рукам. Даже variadic templates можно отложить на потом.
Концепты же радикальным образом упрощают написание сложного шаблонного кода, делают его значительно более читаемым, но при этом представляют собой дополнительную сущность, которую также приходится изучать.
Слежу за развитием С++ тут на Хабре, но что-то пропустил — кто предлагает новые идеи для включения в язык? Любой желающий? И потом идея должна набрать сколько-то голосов, чтобы её начали изучать?
C++ по итогам 2022-го