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

Нет, просто уже привык, что упоминание N-word это сродни упоминаню русского Х-слова. В приличном обществе не принято.

В приличном обществе не принято.

Помни, что нет тюрьмы, страшнее чем в голове.

Ты во всех тюрьмах побывал?

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

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

Вот всегда так у растовиков, как только до дела доходит, так сразу начинается: «не могу», «не помню», «не получается», «ничего нет» и т. д.

но ведь семантика в русском и английском разная

за продвинутые фичи

Кхм, а где в современном C++ продвинутые фичи?

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

Кхм, да любые. Лично я считаю, что максимально допустимый порог от внесения изменений до наблюдения эффекта составляет около 15 секунд. В идеале не больше 2 секунд. А если требуется 5 минут, чтобы узнать, починено ли что требовалось починить (и еще N часов на полный запуск тестов, чтобы проверить не сломалось ли чего), то настала пора менять инструмент.

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

Это проще/короче/в голову не пришло, что можно по-другому. И потом, с какой гордостью люди говорят о том, что у них «header-only» библиотека, ведь линковка — это так сложно. Не говоря уже о том, что спроектировать что-то со стабильным ABI под силу очень немногим C++ разработчикам.

Кхм, а где в современном C++ продвинутые фичи?

Да хотя бы variadic templates, constexpr, автоматический вывод типов параметров шаблонов.

Кхм, да любые.

Еще один звиздун-теоретик. Так уж сложно пример привести, если «да любые»?

Лично я считаю, что максимально допустимый порог от внесения изменений до наблюдения эффекта составляет около 15 секунд.

Каких изменений? Куда?

Дайте пример

Тестирование разработчиком своей работы, какие ещё примеры нужны?

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

Это всё какое отношение к проблеме долгой сборки имеет?

Куда?

В utils.hpp, лол :)

Тестирование разработчиком своей работы, какие ещё примеры нужны?

Примеры типов работы (программистской, естественно), для которых сборка в 5 минут влияет на производительность программиста. Например, формошлепство, драйверописание, разработка внутренних библиотек, саппорт древнего кода на COBOL-е и т.д.

Это всё какое отношение к проблеме долгой сборки имеет?

Встречный вопрос: какое отношение долгая сборка имеет к продуктивности программиста?

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

Это уже вопрос привычки. Проще иметь одну модель для всех языков.

Примеры типов работы

Чёт ты шлангуешь сегодня больше обычного. Я уже написал - тестирование разработчиком своей работы. В какой-то «программистской» работе этот этап отсутствует что-ли? Написал и сразу коммит+пуш - где такое есть?

Встречный вопрос

Да нет уж, сначала ответ, потом уже встречные вопросы

Да хотя бы variadic templates

Это скорее работа над ошибками. Кстати, а их разве не в C++11 завезли?

constexpr

До сих пор не догнали Lisp родом из шестидесятых.

автоматический вывод типов параметров шаблонов

Честно говоря, метапрограммирование поверх pattern matching крайне фиговая идея вцелом. В основном из-за того, что человеку этим крайне ненаглядно пользоваться в отличие от упомянутого выше defmacro.

Еще один звиздун-теоретик. Так уж сложно пример привести, если «да любые»?

Ну вот пришла мне задача «сделать цветное логгирование, если /dev/stderr — это терминал». Вцелом фигня, делов пару десятков строк, т. е. на полчаса.

Однако если от правки до запуска (мы ведь здесь все сознательные и проверяем, что даже очевидные правки работают как ожидалось?) проходит 5 минут, то каждая моя тупая опечатка (а такие обязательно будут, ведь я практикую C-c/C-v) будет увеличивать время на 5/30=16.7%. А затем еще и тестов перед мерджем дождаться надо, и хорошо если они не флапнут.

Вот так вот и оказывается, что получасовая задача на деле будет замержена в лучшем случае часа через 4, а в худшем и вовсе через пару дней. Но за все ведь платит работодатель, не так ли?

Каких изменений? Куда?

Поменял код -> откомпилировал -> увидел результат изменений. Почему надо разжевывать такие тривиальные вещи?

Встречный вопрос: какое отношение долгая сборка имеет к продуктивности программиста?

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

Чем предлагаешь заняться во время компиляции? «Переключиться на другую задачу»?

кто-то слишком нетерпеливый

Мне не комфортно постоянно вылетать из «состояния потока». За 5 минут можно вообще забыть, что там хотел сделать, если текущая идея зафейлится.

признак неустойчивости индустрии - когда такие эфемерные явления источник добавленной ценности.

Точно, надо стартап делать, привлекать инвестиции! иначе так и останется мутной идеей в голове, а так хотя бы профит будет.

драйверописание

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

падажжы, это как надо править код чтобы каждый тык в файле занимал 5 минут на компиляцию? рекомпиляция всего проекта на каждый чих? Или этот самый логгинг в hpp хидере и изменение в нём ломает всех? Ну тогда ССЗБ.

Ты же понимаешь, что N-word и негр/negro – это разные слова?

Написал и сразу коммит+пуш - где такое есть?

Говорят, люди там тесты пишут. Врут, наверное.

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

А как же «изучать поведение железки методом тыка»? Можно прототип написать, конечно, но не то.

Говорят, люди там тесты пишут

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

Так это само делается, можно сходить и выпить чаю. А руками тестировать – фи, пусть этим макаки занимаются.

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

падажжы, это как надо править код чтобы каждый тык в файле занимал 5 минут на компиляцию?

Линковка же ещё.

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

Одно другому не мешает

инклуды не надо будет парсить.

Мне казалось, они просто подставляются как текст :(

Чёт ты шлангуешь сегодня больше обычного.

Это следствие общения с унылыми пустозвонами без проблесков сознания, которые не могут ни в конкретику, ни в логику.

Я уже написал - тестирование разработчиком своей работы. В какой-то «программистской» работе этот этап отсутствует что-ли?

Какой именно работы?

Что вам мешает написать что-то вроде «я клепаю формы на Qt и если при изменении размеров контрола на форме мне нужно ждать пять минут перекомпиляции прежде чем я увижу насколько лучше стала выглядеть форма, то это снижает мою продуктивность»?

Так что вопрос все еще остается без ответа.

Да нет уж, сначала ответ, потом уже встречные вопросы

Ну так перестаньте задавать встречные вопросы и дайте, в конце-концов, конкретный ответ.

Не, в С++ ещё не так всё плохо. На хромой lgbtq/diversity козе пока не подъедешь. Хотя, дела уже движутся в данном направлении.

Это скорее работа над ошибками.

Какими ошибками? В 90-е, когда над C++98, про variadic-и и не задумывались даже.

Кстати, а их разве не в C++11 завезли?

А что, C++11 уже перестал быть современным C++? Если что, то напомню, что стандарта C++20 еще нет. Работа над черновиком стандарта завершена, но самого стандарта еще нет.

До сих пор не догнали Lisp родом из шестидесятых.

Во-первых, что же вы Lisp-ом то не пользуетесь?

Во-вторых, специально для вас, еще раз, чтобы даже вы поняли:

• если вам достаточно подмножества «Си с классами», то скорость компиляции такого кода будет отличасться от скорости компиляции Си-шного кода незначительно. Будет у вас 0.5s на компиляцию файла вместо 0.2s, вы этого и не заметите;
• если вам недостаточно такого подможества, то вы начинаете использовать продвинутые возможности С++. Шаблоны и constexpr в частности. Эти возможности «продвинутые» по сравнению с подмножеством «Си с классами». Если вы хотите сравнить их «продвинутость» с возможностями других языков – то страдайте такой херней, пожалуйста, без меня.

а такие обязательно будут, ведь я практикую C-c/C-v

Это многое объясняет.

Поменял код -> откомпилировал -> увидел результат изменений. Почему надо разжевывать такие тривиальные вещи?

Потому, что у всех работы разные. И мне реально интересно, какой херней должен страдать на работе программист, чтобы компиляция длительностью в 5 минут снижала его продуктивность.

Но если этот программист методом копипасты за полчаса клепает на коленке цветное логирование на терминал, то как-то картинка проясняется.

Инфа

distcc или icecc

Деньги. Для больших коммерческих разработок MSVS покупать нужно.

Вопиющее 4.2 каких-то астрономических масштабов.

Покупать надо студию для коммерческой разработки или старше «экспресс».

Компилятор со всем сопутствующим раздаётся бесплатно уже лет 10, наверно.

А парсер потом этот текст не читает? Сколько строк условно iostream? А если imgui? Или ещё какая header-only развлекуха?

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

Я про тот этап когда ты написал, не работает и думаешь что не так на этот раз

Читает, уже читает всё вместе, словно это один файл.

Хотелось бы цинк увидеть.

А в беседе на русском языке среди посторонних американцев ты будешь избегать слова «книга»?

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

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

А если берём какую-нибудь header-only библиотеку, то там не только отпарсить, а ещё и код компилировать придётся.

iostream - хороший пример.

$ cat a.cpp
#include <iostream>

int main() {}

$ cpp a.cpp | wc -l
28266

Это следствие общения с унылыми пустозвонами без проблесков сознания, которые не могут ни в конкретику, ни в логику.

Возможно, что у вас просто разные темпераменты. Вот, для тебя важны факты, ты несколько раз об этом упоминал. В таком случае может оказаться, что ты «сенсорсный логик». А если для него важны не факты, а сами идеи, то это уже не «сенсорик», а скорее «интуит». Не стоит из этой мухи раздувать слона. Вы, возможно, просто по-разному мыслите.

Честно говоря, метапрограммирование поверх pattern matching крайне фиговая идея вцелом. В основном из-за того, что человеку этим крайне ненаглядно пользоваться в отличие от упомянутого выше defmacro.

А можно на примере?

А что слышно про метаклассы, кстати, кто в курсе?

Если в этом плане, то да.

Говорят, что в лучшем случае в C++23, но это не точно.

Современные компиляторы парсят C++ код с очень высокой скоростью. На reddit-е вроде писали, что VC++ может порядка 1MLOC в секунду проглатывать.

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

В результате, например, у меня тест для header-only библиотеки с шаблонами внутри компилируется порядка 20 секунд, но собственно разбор файлов там – это первые секунда-две. Это очень хорошо видно, когда где-то синтаксическая или даже семантическая (типа неподходящий тип параметра шаблона) ошибка обнаруживается. Компилятор в этом случае отрабатывает за секунду, ну за три максимум.

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