Здравствуйте, maks1180, Вы писали:
M>Но тут важно это сделать так что-бы при ошибки компилятор выдавал название и строку из оригинального файла, а не из созданного парсером.
Это как раз не проблема, есть прагма, которая эту информацию устанавливает для сгенерированного файла.
vsb>Мне кажется, лучше попробовать разобраться с предкомпилированными заголовочными файлами.
Это да, но я перешёл не из-за скорости компиляции, а из-за
1) можно писать в удобном стиле, когда деларация и имплементация сразу.
2) не нужно заботиться о указании noexcept так как когда все функции в одном объектном файле, компилятор сам может правильно определить данный атрибут функции.
Да и вообще код получается более отпимизирован, если компилятор видит сразу все функции.
Здравствуйте, maks1180, Вы писали:
M>Покритикуйте плиз такой метод компиляции, создаётся файл main.cpp в него добавляются M>#include myfile1.cpp" M>#include myfile2.cpp" M>и так далее, далее gcc main.cpp компилируется за 1 вызов. M>Может быть можно это сделать без создания временного файла main.cpp ?
gcc myfile1.cpp myfile2.cpp -Os -o program.exe ?
M>Может я что-то упустил ? Покритикуйте плиз аргументированно.
В большом проекте нужна инкрементальная сборка и пофайловая компиляция поэтому.
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, maks1180, Вы писали:
M>>Покритикуйте плиз такой метод компиляции, создаётся файл main.cpp в него добавляются M>>#include myfile1.cpp" M>>#include myfile2.cpp" M>>и так далее, далее gcc main.cpp компилируется за 1 вызов. M>>Может быть можно это сделать без создания временного файла main.cpp ?
_>Нормальный способ это когда каждый файл .cpp компилируется в объектниек и складывается в библиотеку, которые потом подключаются
Это опасная ловушка. Не нужно делать библиотеку, если вам не нужна осознанно именно библиотека.
Потому, что потом запросто можно наделать в разных объектниках дублирующиеся символы, и слинкуется какой попало.
Если конечно не линковать через -Wl,--whole-archive.
M>>Покритикуйте плиз такой метод компиляции, создаётся файл main.cpp в него добавляются M>>#include myfile1.cpp" M>>#include myfile2.cpp" M>>и так далее, далее gcc main.cpp компилируется за 1 вызов. M>>Может быть можно это сделать без создания временного файла main.cpp ?
fk0> gcc myfile1.cpp myfile2.cpp -Os -o program.exe ?
Это будет — компилирования по отдельности cpp файлов и линковка
Здравствуйте, maks1180, Вы писали:
M>Может я что-то упустил ? Покритикуйте плиз аргументированно.
на конференции C++ Russia был интересный доклад по unity build. Его не нашёл, кину статью от PVS https://habr.com/ru/company/pvs-studio/blog/344534/
Можно только добавить к вашему подходу, что надо делать не один большой файл, а N больших (где N — количество ядер).
Ну и надо искать готовое решение. Самому устранять все неоднозначности макросов, анонимных namespaces будет нелегко.
Меня в самом подходе смущает только описание ошибок компиляции. Оно в С++ хромает (хорошее, но хромает). А после слияния будет вообще мрак. Ведь ссылка идёт на место в сгенерированном временном файле. И закрадывается главный вопрос: "стоит ли овчинка выделки?"
Здравствуйте, maks1180, Вы писали:
M>>>Может я что-то упустил ? Покритикуйте плиз аргументированно.
fk0>> В большом проекте нужна инкрементальная сборка и пофайловая компиляция поэтому.
M>На стадии разработки возможно, если так будет быстрее компилироваться. Но на стадии релиза нет, так как она создаёт менее оптимизированный код.
Для более оптимизированного кода есть LTO. Про анонимные неймспейсы кто-то уже в треде высказался -- включать всё через include ещё та глупость,
которая может породить трудно выявляемые баги.
Здравствуйте, maks1180, Вы писали:
M>>>Покритикуйте плиз такой метод компиляции, создаётся файл main.cpp в него добавляются M>>>#include myfile1.cpp" M>>>#include myfile2.cpp" M>>>и так далее, далее gcc main.cpp компилируется за 1 вызов. M>>>Может быть можно это сделать без создания временного файла main.cpp ?
fk0>> gcc myfile1.cpp myfile2.cpp -Os -o program.exe ?
M>Это будет — компилирования по отдельности cpp файлов и линковка
Ну зато "без создания временного файла" (на самом деле компилятор где-то в /tmp что-то создаст наверное...)
Unreal Engine использует unity build по дефолту, чем они порядочно увеличили скорость компиляции своей эпичной кодобазы.
Там где то по 10ти исходников компиляются как один.
Т.е. подход в целом работает, но нужно искать какой то баланс самому либо тулзами. Такой подход ест достаточно много оперативки. И страдает инкрементальный билд, хотя линковка может ускориться — нужно мерять.
В общем неблагодарное это дело, я бы просто C++ модулей дождался.
Здравствуйте, maks1180, Вы писали:
M>Покритикуйте плиз такой метод компиляции, создаётся файл main.cpp в него добавляются M>#include myfile1.cpp" M>#include myfile2.cpp" M>и так далее, далее gcc main.cpp компилируется за 1 вызов. M>Может быть можно это сделать без создания временного файла main.cpp ?
Это называется "амальгамация". Некоторый софт так распространяется, у SQLite, например, есть амальгамированная версия
M>Преимущество: M>- время сборки целиком проекта значительно быстрее. Например препроцессор добавляет 2Мб в каждому файлу где есть #include <windows.h>
Препроцессор — это фигня, это довольно тупая текстовая обработки
M>- не нужно заботиться о указании noexcept так как когда все функции в одном объектном файле, компилятор сам может правильно определить данный атрибут функции. M>- можно писать в удобном стиле, когда деларация и имплементация сразу. Есть какой-то термин для данного стиля ?
Header-only библиотека? А что мешает писать в таком стиле без сваливания всего в одну кучу?
M>Может я что-то упустил ? Покритикуйте плиз аргументированно.
Это удобно для распространения библиотеки в сорцах, чтобы пользователю не возится с кучей сорцов, а подключать один файл. В процессе разработки — это куча граблей на ровном месте. Можно, но зачем?
