Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) (а изначально так и вовсе доходило до 40, пока не сделал максимальную развязку). Ситуацию усугубляет повсеместно внедрение шаблонов, которые еще больше увеличивают это время. Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции.
Из тех мер, что предлагается, самая естественная — forward declaration, но, во-первых, она работает только с классами верхнего уровня (сделать что-то наподoбие class CFoo::CSubFoo; уже нельзя), а во-вторых, и там есть подводные камни: Google C++ Style Guide/Forward_Declarations.

Разработчики языка вообще в эту сторону смотрят?

Здравствуйте, _hum_, Вы писали:

У нас полная перекомпиляция проекта на icore 5 занимает порядка 2 часов. Причем "светлые головы" заставили отказаться от предкомпилированных заголовков, т.к. Jenkins'у от них плохо становится.

Здравствуйте, Qt-Coder, Вы писали:

QC>Здравствуйте, _hum_, Вы писали:

QC>У нас полная перекомпиляция проекта на icore 5 занимает порядка 2 часов. Причем "светлые головы" заставили отказаться от предкомпилированных заголовков, т.к. Jenkins'у от них плохо становится.

я немного про другое спрашивал — как с такими временами перекомпиляции можно выполнять разработку проекта (тот же дебагинг)?

Здравствуйте, _hum_, Вы писали:

__>я немного про другое спрашивал — как с такими временами перекомпиляции можно выполнять разработку проекта (тот же дебагинг)?
Я говорил про полную перекомпиляцию. При отладке меняется один юнит и его перекомпиляция плю слинковка не занимают много времени.

Здравствуйте, _hum_, Вы писали:

__>Разработчики языка вообще в эту сторону смотрят?

Смотрят, конечно, но модули в с++17 все-таки не попали.
Команды разработчиков иногда используют Incredibuild или distcc.

Здравствуйте, _hum_, Вы писали:

__>Разработчики языка вообще в эту сторону смотрят?

Конечно. Модули — первый и самый главный шаг.

__>Ситуацию усугубляет повсеместно внедрение шаблонов, которые еще больше увеличивают это время.
Тут первичная проблема в header-only библиотеках. Если шаблонная магия находится не в заголовочном файле, который включается в пол-программы, а внутри соответствующего cpp, то ничего страшного не происходит.

__>Не совсем понимаю, как разрабатываются большие проекты на С++?
Бьют на изолированные части. Можно вполне собирать программу из сотни статических библиотек, каждая из которых, довольно слабо связана с остальными. Ну и использовать header-only библиотеки по минимуму. От всяких глобально видимых shared_ptr, конечно, не уйдёшь. Но в остальных случаях можно завернуть такую шаблонную библиотеку в обычную статическую, предоставив наружу простой интерфейс.

Ну и можно просто сам процесс ускорить, перейдя на распределённую сборку (distcc), кеширование объектников (ccache) и даже на использование более быстрых утилит и компиляторов (вроде gold линкера).

Здравствуйте, _hum_, Вы писали:

__>Разработчики языка вообще в эту сторону смотрят?
Просто дроби на либы и компилируй по частям.

Здравствуйте, Qt-Coder, Вы писали:

QC>Здравствуйте, _hum_, Вы писали:

__>>я немного про другое спрашивал — как с такими временами перекомпиляции можно выполнять разработку проекта (тот же дебагинг)?
QC>Я говорил про полную перекомпиляцию. При отладке меняется один юнит и его перекомпиляция плю слинковка не занимают много времени.

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

__>Разработчики языка вообще в эту сторону смотрят?
Ээм, что ты такое строишь. У меня рабочий проект, чуть больше миллиона строк кода, строится на не самом быстром серваке часа полтора.Под строится — понимаю только фазу сборки бинарников. Можно распараллелить сборку всякими тулами и сделать за полчасика , только времени на эту работу никто не дает, пока всех и так устраивает.

Здравствуйте, Kernan, Вы писали:

K>Здравствуйте, _hum_, Вы писали:

__>>Разработчики языка вообще в эту сторону смотрят?
K>Просто дроби на либы и компилируй по частям.

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

Здравствуйте, Temnikov, Вы писали:

__>>Разработчики языка вообще в эту сторону смотрят?
T>Ээм, что ты такое строишь. У меня рабочий проект, чуть больше миллиона строк кода, строится на не самом быстром серваке часа полтора.Под строится — понимаю только фазу сборки бинарников. Можно распараллелить сборку всякими тулами и сделать за полчасика , только времени на эту работу никто не дает, пока всех и так устраивает.

а как вы дебагинг делаете? ведь как правило несколько десятков исправлений приходится за день вносить при разработке.

Здравствуйте, _hum_, Вы писали:

__>то есть, в больших проектах как правило происходит уменьшение связей между частями таким образом, чтобы эти части можно было оформить в виде независимых единиц компиляции?

Необязательно. Достаточно просто аккуратно прописывать include-ы (и максимально использовать упомянутые fwd include-ы), чтобы не было такого, что все включается во все.
Тогда будет пересобираться только то, что необходимо.
Ну и параллельный make никто не отменял, только, опять же, он должен быть разумно написан.

You will always get what you always got
  If you always do  what you always did

__>>Разработчики языка вообще в эту сторону смотрят?
T>Ээм, что ты такое строишь. У меня рабочий проект, чуть больше миллиона строк кода, строится на не самом быстром серваке часа полтора.Под строится — понимаю только фазу сборки бинарников. Можно распараллелить сборку всякими тулами и сделать за полчасика , только времени на эту работу никто не дает, пока всех и так устраивает.
Несколько лет назад оптимизировал рабочий билд сервер, там почти двухкратный прирост скорости дал просто перенос машины (это виртуалка на сервере), на другой сервак с быстрым диском (NAS), если закинуть все на SSD, было б ещё быстрее.

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, _hum_, Вы писали:

__>>то есть, в больших проектах как правило происходит уменьшение связей между частями таким образом, чтобы эти части можно было оформить в виде независимых единиц компиляции?

J>Необязательно. Достаточно просто аккуратно прописывать include-ы (и максимально использовать упомянутые fwd include-ы), чтобы не было такого, что все включается во все.
J>Тогда будет пересобираться только то, что необходимо.
J>Ну и параллельный make никто не отменял, только, опять же, он должен быть разумно написан.

если "необязательно", то тогда ж принципиально невозможно обойтись без перекомпиляции связанных частей (манипуляции с инклюдами и форвардами позволяют только технически развязать то, что ЛОГИЧЕСКИ развязано)

Здравствуйте, Temnikov, Вы писали:

__>>>Разработчики языка вообще в эту сторону смотрят?
T>>Ээм, что ты такое строишь. У меня рабочий проект, чуть больше миллиона строк кода, строится на не самом быстром серваке часа полтора.Под строится — понимаю только фазу сборки бинарников. Можно распараллелить сборку всякими тулами и сделать за полчасика , только времени на эту работу никто не дает, пока всех и так устраивает.
T>Несколько лет назад оптимизировал рабочий билд сервер, там почти двухкратный прирост скорости дал просто перенос машины (это виртуалка на сервере), на другой сервак с быстрым диском (NAS), если закинуть все на SSD, было б ещё быстрее.

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

__>а как вы дебагинг делаете? ведь как правило несколько десятков исправлений приходится за день вносить при разработке.
Ну про несколько десятков ты загнул. Обычно меняешь 1-2, ну 3 модуля связанных друг с другом. Изменений конечно может быть и много.
Вся программа состоит из порядка 200+ бинарей, сам по себе отдельный бинарник строится макисмум минут 5 на разработческом железе (ноутбучные i5-ые процы). Мелкие модули быстрее.
Билд-сервер строит 2е версии бинарей, релизные и дебажные. Программу можно накатить инсталлятором в дебаг версии. Соотвественно, дальше разработчик меняет нужную ему библиотеку и отлаживает её в составе программы, которая уже собрана в дебаг версии и нормальна дебажится. К этому всему делу рядом ещё живет символ-сервер.

__>нуу, то есть, за счет железа...
А почему бы и нет? Прогресс ведь не стоит на месте. Это было на тот момент бесплатно, тк серваки уже были в наличии, там были нагрузочные лабы, которые перенесли на другое железо. Просто переиграли что где хостится.


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

__>Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) (а изначально так и вовсе доходило до 40, пока не сделал максимальную развязку). Ситуацию усугубляет повсеместно внедрение шаблонов, которые еще больше увеличивают это время. Все бы ничего, но невозможно же дебаггинг проводить — одно исправление — и опять длительное ожидание перекомпиляции.
Ну и железо вроде как не шибко быстрое. У меня ноут i5, 16 гигов оперативы, чисто субъективно, стало быстрее работать при увеличении с 8 до 16 гигов ОЗУ. Свопиться скорее всего меньше стал. Ну и 2-3 виртуалки на компе легче по этой же причини держит.

А можно метрики проекта? Сколько строк кода, какие библиототеки используете?

Здравствуйте, watchmaker, Вы писали:

W>Тут первичная проблема в header-only библиотеках. Если шаблонная магия находится не в заголовочном файле, который включается в пол-программы, а внутри соответствующего cpp, то ничего страшного не происходит.

Мой подход такой:
хедеры для header-only компонента А делятся на три категории:
1. a_fwd.h — Чистый forward declaration: только пространства имен, имена классов и функций в них. Подключаются там, где нужно просто имя типа/функции (например, переменная-указатель на тип).
2. a.h — "нормальный хедер": пространства имен, определения классов, но для тяжелых функций (тяжелых как в смысле кода, так и в смысле зависимостей) — только прототипы. Подключаются там, где нужно создавать объекты класса и вызывать легкие функции.
3. a_impl.h — определения тяжелых функций. Подключаются только там, где они вызываются.

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

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, watchmaker, Вы писали:

W>>Тут первичная проблема в header-only библиотеках. Если шаблонная магия находится не в заголовочном файле, который включается в пол-программы, а внутри соответствующего cpp, то ничего страшного не происходит.

J>Мой подход такой:
J>хедеры для header-only компонента А делятся на три категории:
J>1. a_fwd.h — Чистый forward declaration: только пространства имен, имена классов и функций в них. Подключаются там, где нужно просто имя типа/функции (например, переменная-указатель на тип).
J>2. a.h — "нормальный хедер": пространства имен, определения классов, но для тяжелых функций (тяжелых как в смысле кода, так и в смысле зависимостей) — только прототипы. Подключаются там, где нужно создавать объекты класса и вызывать легкие функции.
J>3. a_impl.h — определения тяжелых функций. Подключаются только там, где они вызываются.

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

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