hpp vs cpp

Да никаких проблем. Курятник с помощью гвоздей сколотил - и небоскрёб сдюжишь. Сварка - она же лишь скрепляет детали в том или ином виде. Уверен, во всех небоскрёбах используют гвозди.

Попробуй что ли реально написать мейкфайл для сборки какого-нибудь хромиума что ли. Потому что воображаемая работа - она всегда легкая.

мейкфайл для сборки какого-нибудь хромиума

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

В теории могли бы делать и для gmake, но за десятки лет никто не сделал. И всё что есть для CMake реализовать для gmake потребует сотни человеко-лет.

Ну вот на это я согласный

Там кто-то заявлял что готов за вечер «make» реализовать. Смело

Да не на 100 процентов совместимый, а реализующий саму идею с набором таргетов и зависимостей, которые раскручиваются. Про «за вечер» я, конечно, загнул, но не сильно.

Я сторонник идеи «резать мелко»,

Я тоже, но наш-то спор давно отвалился от материнского топика

И таки удачи Вам с Вашими проектами: чую одним местом - она Вам пригодится…

Спасибо за снисходительность :)

ПыСы: меня можно «на ты»: я – парень простой

Да никаких проблем. Курятник с помощью гвоздей сколотил - и небоскрёб сдюжишь. Сварка - она же лишь скрепляет детали в том или ином виде. Уверен, во всех небоскрёбах используют гвозди.

Ерничай-ерничай. Не по делу ж говорить. Я показал что мейк может вызывать подпрограммы. И все твои космические сложности, которые ты пророчил, точно так же решаются в две строчки – вызовом подрограмм. На это что ответишь, кроме «вы не понимаете, это – другое» и «ты пацан просто жизни еще не знаешь» ?

Попробуй что ли реально написать мейкфайл

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

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

Ну скатись еще в обсирание в третьем лице в присутствии обсираемого.

Я так и не услышал от тебя в чем проблема-то? Складывается впечатление что ты не понимаешь, а делаешь умный вид.

Да нет никаких проблем. Устраивает тебя мейк - пользуйся этой смоляной ямой. Прости, но опыт использования не передаётся буковками.

Вот тебе преимущества cmake над make+bash

• стандарт
• размер кода
• наличие готовых рецептов
• скорость внесения изменений
• поддержка IDE

Вот мне просто интересно, вас с народом выше, не смущает, то вы сравниваете генераторы сценариев для «сборщика» и собственно «сборщик»? Ладно бы ещё с make с ninja воевали или cmake/meson с autotools.

ну это не совсем так. Ну, то есть, технически – так, а место в экосистеме – конкурирующее

make не сборщик, это вызыватель команд согласно сценарию

Ну, как-бы я поэтому и поставил в кавычках.

Как оно может конкурировать, если без второго в принципе жить не может?

Писать Makefile для какого-нибудь условный GIMP я бы не согласился даже за много денег. Про какой-нибудь Chrome/Firefox/Blender я в принципе не говорю.

Как оно может конкурировать, если без второго в принципе жить не может?

в 2023 CMake почти никто не использует совместно с gmake, так как есть Ninja который тупо быстрее.

Как оно может конкурировать, если без второго в принципе жить не может?

Это легаси. Исторически сложилось. Некоторые сборочные системы могут и сами напрямую вызывать компилятор. Закопанный qbs, например.

Ну справедливости ради я бы не отказался от мекфайла для хромиума. Там треш а не билд.

ну, в треде про нинзю и не вспоминали, хотя казалось-бы.

/me лихорадочно ищет в треде qbs. Весь тред сводится к : высокоуровневые системы сборки vs. «деды собирали»

Ну справедливости ради я бы не отказался от мекфайла для хромиума. Там треш а не билд.

Я как-то пытался собрать, там специальная инструкция для тупых: скриптик, который якобы все сдалает за меня. Сутки тянулось, сутки собиралось – не осилило по памяти на 16 гигах. Вот это как так? Там че, реально все в один файл слепляют перед компиляцией? Как так можно? Тьфу!

в треде про нинзю и не вспоминали

Было же, причем на прошлой странице

Весь тред сводится к : высокоуровневые системы сборки vs. «деды собирали»

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

Makefile писать руками для чего-то больше какого-нибудь мелкого драйвера шибко много/долго/дорого (да и и ещё эта ё*ая табуляция). Автоматизации хочется. Ну вот тулзы/cmake/etc. и есть эта самая автоматизация. Плюсом gmake ещё и довольно торомозной - отсюда родилась ninja.

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

Я как-то пытался собрать, там специальная инструкция для тупых: скриптик, который якобы все сдалает за меня. Сутки тянулось, сутки собиралось – не осилило по памяти на 16 гигах. Вот это как так? Там че, реально все в один файл слепляют перед компиляцией? Как так можно? Тьфу!

Хз про конкретно хромимум, но LTO люто до памяти жадно бывает.

Нет. Тебе нужно парсить файлы, чтобы достать инклюды

По-моему, GCC с этим сам справляется.

и также отслеживать в них изменения

А с этим — make.

Инклюд шаблонов не влияет почти ни на что

Во-первых, влияет. Потому что

% wc -l main.cpp
7 main.cpp

превращается в

% g++ main.cpp -E -I. | wc -l
33744

строк, которые нужно как минимум распарсить, что в случае С++ является нетривиальной задачей. И так для каждого файла.

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

инстацированием сложных шаблонов в одной единице трансляции и дальше линкер в помощь

Это заведомо нерабочий подход, потому что шаблоны на то и шаблоны, что инстанциируются для множества типов, в том числе неизвестных в отдельно взятой единице трансляции. Не говоря уже об уникальных типах (decltype([]{})), да и самой по себе необходимости отслеживать используемые типы и заносить их в файл.

Не более чем твой шаблонный фанатизм

Вперед, выпиливайте STL. Постоянно вижу «антишаблонизаторов», которые призывают выпилить шаблоны из С++. Умные указатели, контейнеры и алгоритмы они почему-то выпиливать не хотят – загадка.

при позднем связывании в плугинах очень даже норм

Каждый .cpp файл порождает объектник, которые затем влинковываются в таргет. Так происходит с каждым .cpp файлом в каждом проекте на С и С++. Ваши плагины на этом фоне составляют мизерные доли процента.

Лично я видел templates.cpp который собирался двое суток из-за злоупотребления авторами шаблониумом :)

Верю. Разбейте на templates1.cpp и templates2.cpp – и будете собирать четверо суток.

Сборке мира, из-за пары строчек, которая нужна не всем.

Каким образом это контрпример?

Только не надо демонстрировать циферки на пустых файлах.

Файлы не пустые – взгляните парой сообщений выше. Или 34 тысячи строк для вас какая-то шутка? А это ведь всего лишь <iostream>.

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

что ни один из проходов выполняемых компилятором не хуже O(N).

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

потому что в хедерах кода нет, там только объявления

Да? 3036 строк сплошных объявлений, никакого кода

https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a00770_source.html

Как обычно, 5 звезд.

строк, которые нужно как минимум распарсить, что в случае С++ является нетривиальной задачей.

По сравнению с компиляцией с опцией -О3 парсинг это ерунда. Более того, у меня в некоторых проектах кодогенератор выдаёт такое шо без всяких шаблонов компилятор думает минут по дцать, и хорошо если в итоге не падает.

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

Прости, но опыт использования не передаётся буковками.

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

По сравнению с компиляцией с опцией -О3 парсинг это ерунда

Есть какие-то бенчи? Мне казалось я встречал инфу что от опций оптимизации время сборки сложного C++-кода зависит несильно. Ещё такие картинки есть https://www.phoronix.net/image.php?id=2019&image=llvm_time_trace_show https://aras-p.info/img/blog/2019/clang-timereport-teaser.png

По сравнению с компиляцией с опцией -О3 парсинг это ерунда.

вот тут жаловались на то что лишь добавление include некоторых хедеров без их использования стало замедлять компиляцию в С++20.

https://www.reddit.com/r/cpp/comments/o94gvz/what_happened_with_compilation_times_in_c20/

Так что парсинг тоже стоит времени, но да оптимизации больше времени занимают.

Да? 3036 строк сплошных объявлений, никакого кода

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

Как обычно, 5 звезд

Звёздочками иди с одноклассниками мериться, а когда влезаешь в разговор взрослых, будь добр хотя бы разобраться о чём идёт речь.

надо найти спеца

доку надо прочитать, а не спеца искать

версия смаке слишком старая

для контроля окружения есть решения навроде докера

Ога-ога, все в докер завернуть и неделями доки штурмовать.

А потом удивляются что хеллоуворлд пишется месяц и занимает дцать гб.

Есть личный опыт. Субьективно включение -О3 тормозит сборку на порядок как мин. Но понятно что это зависит от кода.

Да-да, вы правы. Докер - это сложна-а и вообще хипсторы придумали. А читать - не барское дело. Так, интернетик полистать, руга-ають. Гигабайты на хуловорд! Сварочники эти едрить-мандрить, спеца пойди найди, чтоб ток выставил. Ну его, вот гвозди - это вещь! Дед курятник сколотил, до сих пор стоит!

MSVC

Нерелевантно на этом ресурсе.

Или 34 тысячи строк для вас какая-то шутка?

«Напугали ежа голой жопой», что называется. Вот смотрю я на один из наших .cpp в 53k строчек (криминал, я знаю - corner case), который после препроцессора раздувается в 345k строк. И что?

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

Вот реально не думал что конкретно Вам мне это придётся разжёвывать…

Вам очевидно что тривиально показывается что если предел f(N) / g(N) при N стремящемся к бесконечности стремится к бесконечности, то для любого M найдется такой N что f(N) / (M * g(N/M)) больше единицы?

Зачем делать сложно когда можно сделать просто?

Для каждой задачи хорош свой инструмент. Это религиозное что то, пихать докер-смаке во все дырки? Сюда же можно отнести хмл/жсон/sql/иксель - кто на что учился…

Если для Ваших задач докер-смаке хорош, с чего Вы взяли что везде так? Если Вы других задач не встречали, то это говорит только о Вашем кругозоре а не о докере. Простите что приходится разжевывать Вам такие элементарные вещи.

Вы ещё на стиралки с микроволновками докер ставить предложите…

есть ещё H и C подход…

шаблонный код, который нигде кроме заголовков находиться не может

Одна из самых ржачных нелепых багофич плюсов. Только из-за этого стоило бы перейти на Go или Rust.

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

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

Вот смотрю я на один из наших .cpp в 53k строчек (криминал, я знаю - corner case), который после препроцессора раздувается в 345k строк. И что?

Это просто поразительно. У человека .cpp раздувается из-за шаблонов на 300k строк (в 7 раз), и он не видит никакой связи между продолжительностью сборки и количеством .cpp файлов.

Вам очевидно что тривиально показывается что если предел f(N) / g(N) при N стремящемся к бесконечности стремится к бесконечности, то для любого M найдется такой N что f(N) / (M * g(N/M)) больше единицы?

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

Это шаблонный код, который нигде кроме заголовков находиться не может

Шаблонный код может находиться в .cpp файлах.

мы его вообще не обсуждаем.

Обсуждаем.

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

Объем кода, включаемого при использовании одной только стандартной библиотеки, измеряется десятками тысяч строк, что превышает размер типичного .cpp файла.

Поэтому тезис

Компилятор компилирует код, а не файлы. Я показал что кода компилируется больше.

Является неверным.

Касательно «определений», «объявлений» и «кода», предлагаю посмотреть черновик стандарта, а не изобретать собственную терминологию.

https://eel.is/c++draft/basic.def

Хорошо, на зачет по матанализу за первый курс наработали.

Двойка мне, на самом деле. Давайте сначала договоримся согласны ли Вы со следующим:

Если предел f(N) / N при N стремящемся к бесконечности стремится к бесконечности, то для любого M > 1 найдется такой N’ что для всех N > N’ результат f(N) / (M * f(N / M)) больше единицы

?

Шаблонный код может находиться в .cpp файлах.

Общий - не может. Локальный мы также не обсуждаем.

Обсуждаем.

Давай-ка ты всё-таки прочитаешь о чём идет речь и прекратишь чушь писать. Ткну носом в ОП:

за и против писать все в заголовочных файлах

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

Кстати, код с локальным скоупом - это ещё один поинт против .h, потому что тогда TU будет один и всё будет в одном скоупе.

Касательно «определений», «объявлений» и «кода», предлагаю посмотреть черновик стандарта, а не изобретать собственную терминологию.

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

Давайте перефразируем на git.

Если для Ваших задач контроль версий хорош, с чего Вы взяли что везде так? Если Вы других задач не встречали, то это говорит только о Вашем кругозоре а не о контроле версий

И уже несколько бредово звучит. Теперь поменяйте контроль версий на контроль окружения. Это примерно одно и то же, только одно применимо к процессу разработки, а второе - к процессу сборки.

Вы ещё на стиралки с микроволновками докер ставить предложите…

А вы, простите, прямо на стиралках свои плюсовые проекты собираете? Вот в сборке для стиралки докер бы помог…

Вы и правда не видите разницы между гитом и докером/смаке? Аналогия (с гитом в тч) не является аргументом или доказательством, но может являться дидактическим приемом.

Я Вам страшную тайну открою, есть люди которые даже без шелла обходятся. Хотя уж шелл то куда востребованней чем гит. Мир большой и разный, и далеко не везде нужен контроль окружения. У нас скажем как правило не нужен. И смаке у нас избыточен. За 20+ лет при мне юзали его ровно два раза, один раз потому что кроссплатформенность и вот это все (и намучались страшно), второй раз просто молодежь баловалась. В остальных случаях обычный gnu make.

А вы, простите, прямо на стиралках свои плюсовые проекты собираете?

По разному, обычно на десктопах/кластерах. Там же где запускаем. И ой, докеров там нету. В облаках правда что то такое есть, но для нас это скорее экзотика (в РФ это сейчас банально дорого).