Стандарт C++20 утверждён

Например?

Да, ужас. Оно с каждым днем все более монстрозное и тормозное. Увы, рынку сойдут и быдлокодеры. Больше синтаксического сахара богу синтаксического сахара!

Оно с каждым днем все более монстрозное

Допустим.

и тормозное.

А вот с этого места поподробнее, пожалуйста.

А потом эти люди ругают Rust за то что фичи появляются слишком быстро.

а в расте можно сделать что-то типа «-std=с++98» на новейшем релизе компилятора?

Погоди, ты сейчас хочешь сказать, что для сборки проекта в CI нужна отдельная копия всей IDE под названием Microsoft Visual Studio?

Я хочу сказать, что у MS есть продукт VisualStudio, который нужно купить, если ваши условия разработки не попадают под ограничения community edition. А после покупки вы можете устанавливать компоненты VS как вам захочется.

Поставляет и без студии в составе Build Tools for Visual Studio 2019. Их загрузка спрятана на страничке загрузки студии.

Ну вот у меня есть вялотекущая попытка сделать поверх solo5(считай low level для unikernel) растовую обёртку с реализацией необходимого минимума ништяков для запиливания «микросервисов», ну там аллокатор, ip стек, экзекутор для футур вот такое вот всё милое и безобидное.

Утыкаюсь я в то, что сборка итогового elf хоть и не сложная, но требует полноценного контроля за выхлопом, плюс несколько совсем кастомных шагов с генерацией сишного кода и запихивания его отдельной единицей трансляции(это уже оверынжынигринг от solo5 но что поделать, апстрим так сказать). cargo в такой конфигурации не то что не помощник, а скорее даже вредитель. Там где на make ты написал себе несколько таргетов и распихал их запуск, пусть не очень удобно, на cargo ты лепишь build.rs где пишешь шелл-скрипт в синтаксисе раста и не имеешь внятного контроля вне build step.

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

Я в итоге делаю по-дурацки, типа с помощью cargo собираю все свои растовые хреновины, а потом уже врукопашную на шелле с помощью какой-то матери собираю итоговый elf.

Да, можно указать rust-2015 и у тебя будет поведение соответствующее тому времени.

пока выпустятся студенты, которые его изучили, пока они дорастут до руководителей проектов

Какие в жопу «руководители проектов»? Ты думаешь, что те, кто заступает на позиции проджект лидов сегодня знают С++11 или вообще С++ какой-либо версии? Бга-га-га. Проджект лид, если речь не о мелкой конторе, такой фигней не занимается, для этого есть специально обученный технический специалист.

Стандарт C++20 утверждён (комментарий)

Если использовал нотацию printf, то придётся переделать как минимум на нотацию из python.

Не придется, использовал python-style форматирование. А иначе какой смысл в fmtlib?

Другое дело, что gcc 9.2 и clang 9.1 о нём ничего не знает даже с флагом -std=c++2a

Ну значит пока рано вырезать fmtlib из проектов.

вы что, хотите сказать что плюсовики сейчас вместо старого доброго printf используют эту хрень?

Зависит от задачи. Но fmtlib весьма хорош и очень быстр.

Ну так всё правильно. Cargo собирает растовские проекты. Больше ничего он делать не должен.

А вот с этого места поподробнее, пожалуйста

Да даже в сравнении с кодом, написанным по старым стандартам, не говоря уже о C.

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

Ну вот это тот 1%, про который я писал. Твой случай очень редкий чтобы его использовать за основу.

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

А у меня считай растовый no_std проект с обвесом вокруг сишного исходника с хитрой линковкой.

А ведь хочется cargo run и не париться, но к сожалению не получается как хотелось бы. Хоть целиком весь solo5 переписывай, благо там не сильно больше чем у https://os.phil-opp.com/ только особенности Xen/KVM учитывать надо.

Да даже в сравнении с кодом, написанным по старым стандартам, не говоря уже о C.

Можете показать код, который на C++98 исполняется быстрее, чем на C++17?

код, который на C++98 исполняется быстрее

Это где я такое писал?

Да вот же:

Оно с каждым днем все более монстрозное и тормозное.

Да даже в сравнении с кодом, написанным по старым стандартам, не говоря уже о C.

Или вы из надмозгов, которые «тормознутость C++» определяют по скорости компиляции?

которые «тормознутость C++» определяют по скорости компиляции?

Тормоза разные бывают. В том контексте — да, тормоза при компиляции, т. е. огромное потребление ресурсов и долгое время компиляции. Вообще «тормоза» — сленг.

Тормоза разные бывают.

Когда говорят, что один язык тормознее другого, то, как правило, подразумевается скорость выполнения программ на этих языках. И накладые расходы, которые накладывает язык во время исполнения кода, написанного на этом языке.

В том контексте — да, тормоза при компиляции, т. е. огромное потребление ресурсов и долгое время компиляции.

Если вы будете оставаться в рамках подмножества C++98, то и тормозов при компиляции у вас не будет.

один язык тормознее другого, то, как правило, подразумевается скорость выполнения программ на этих языках. И накладые расходы, которые накладывает язык во время исполнения кода, написанного на этом языке

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

Ну т.е. бла-бла-бла по образу и подобию незабвенной Iron_Bug. Вы не в одной с ней команде работаете часом?

Или вы из надмозгов, которые «тормознутость C++» определяют по скорости компиляции?

Ну вообще время компиляции — довольно важный показатель. Если после каждого внесения изменения нужно ждать сборки по 5 минут, производительность разработчика падает.

Ну т.е. бла-бла-бла

Нет.

Iron_Bug. Вы не в одной с ней команде работаете часом?

Даже не знаю, кто это.

Ну вот модули обещают это время уменьшить.

Когда поддержка в компиляторах появится? Нет инфы?

Как я понимаю, вам нужен post-build, которого нет (вроде хотели добавить). У меня есть несколько проектов, в которых дикая смесь из C/C++/Rust и cargo build пока что справляется.

Разве? В том же расте тоже модули, но время сборки на уровне C++. Мономорфизацию всё равно делать придётся.

Я ж не говорю что уменьшат.

Хотя в случае плюсов это вполне возможно, просто за счёт того что инклуды не надо будет парсить.

Ну вот модули обещают это время уменьшить.

Не знаю, что там и как обещают модули, но как 10 лет назад сборка плюсовых проектов занимала десятки минут, так и продолжает идти по 30+ минут. И это при том, что производительность железа за десятилетие неплохо так повысилась, а сложность решаемых программистами задач не сильно изменилась.

Типа того, да. pre-build/post-build были бы очень в тему.

Осиль ccache , extern template и precompiled headers.

Осиль ccache

1. Костыль. 2 Не поможет, когда разработчики привыкли писать код в хидерах

extern template

Поможет только в частных случаях.

precompiled headers

Убогий костыль, официально признан тупиковым. И опять-таки не помогает, когда все привыкли писать код в хидерах.

когда все привыкли писать код в хидерах

А зачем это делать, кроме случая header-only библиотеки и может ещё нескольких специфичных?

Это никак не меняет сути моего комментария. Свежепоступившим на работу всё равно потребуется время на прорастание в этих самых «доверенных технических специалистов».

Нет.

Без конкретных примеров «было»-«стало» – это не «нет», а «да». Пустое форумное бла-бла-бла.

Ну вообще время компиляции — довольно важный показатель.

По секрету вам скажу: если вы можете обходиться подмножеством «Си с классами», то скорость компиляции у вас будет лишь немногим хуже, чем у чистого Си.

А если не можете, то о чем вообще разговор: за продвинутые фичи платите либо временем компиляции, либо жопочасами на закат Солнца вручную.

Если после каждого внесения изменения нужно ждать сборки по 5 минут, производительность разработчика падает.

Что же это за работа и задачи такие, где время компиляции в 5 минут начинает влиять на производительность разработчика?

Ну вот у меня есть вялотекущая попытка сделать поверх solo5(считай low level для unikernel) растовую обёртку с реализацией необходимого минимума ништяков для запиливания «микросервисов», ну там аллокатор, ip стек, экзекутор для футур вот такое вот всё милое и безобидное.

Звучит очень интересно. Сам думал о подобном. Поделитесь ссылкой?

и одного black

Справа внизу не black, а индус.

Если после каждого внесения изменения нужно ждать сборки по 5 минут, производительность разработчика падает.

Что же это за работа и задачи такие, где время компиляции в 5 минут начинает влиять на производительность разработчика?

Да любая, за немногими исключениями, может быть. И долгие тесты в ту же кучу

и одного black

боисся, чтоб твои комментарии в русскоязычных интернетах не перевели гугл-транслейтом и атата не сделали? :P

Свежепоступившим на работу всё равно потребуется время на прорастание в этих самых «доверенных технических специалистов».

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

Стандарт и новые фичи создаются для всех, и если есть такая возможность/желание - новые фичи используются, если нет - по крайней мере стараются по максимум ничего не поломать из того, что уже работает. Всё для общества.

Не поможет, когда разработчики привыкли писать код в хидерах

В этом случае вообще ничего не поможет, так что можно не рассматривать. А так ccache штука зачётная

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

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

С каких пор header-only и шаблоны (extern template редко используют) стали чем-то специфичным?

Примерно тогда же, когда лепить код в хедеры стало нормальной практикой.

Я по старой памяти всё ещё считаю что в хедере находятся определения, возможно инлайны и изредка код общего назначения. Запихивать в хедер какой-нибудь imgui я вижу смысл, лепить какой-нибудь класс с бузинес-логикой, уже нет.

Да любая

Да ладно. Дайте пример любой такой, где не нужно ни доки курить, ни думать, ни обмениваться информацией с кем-то еще.

Дополнительные оптимизации требуют дополнительных затрат. А при параллельной сборке и линковке больше ресурсов.

Хотя да, в студенческие годы время компиляции даже вывода helloworld после turbo pascal и delphi очень удручало.

Сильно зависит от задачи. Но в 50/50.