Идея C++ автоматическая система сборки единиц, будет ли она работать?

Question

Так что это может показаться немного сумасшедшим, но у меня была следующая идея:

В C++ они вызывают сборку единства, когда вы помещаете весь свой код в один файл с помощью # include или просто копируете и вставляете. Это позволяет быстро собирать молнии.

Теперь для простоты предположим, что у нас есть только библиотека заголовка, и мы ограничиваемся только использованием классов (таким образом, у нас есть пространство с гараутомным именем). Теперь мне было интересно, как хорошо это сработает, если будет сделано автоматически. Сценарий/инструмент будет создан для предварительной обработки файлов .h; выбор включает и зависимости. Инструмент будет рекурсивно перемещаться каждый .h-файл и строить сопоставление зависимостей include. Затем он будет размещать эти зависимости в одном файле (main.cpp) с помощью #includes и компиляции.

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

Answer 1

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

Это позволяет сделать молниеносную компиляцию.

Это не совсем так. Компиляция не связана с вводом/выводом, если у вас есть выделенный компьютер для компиляции с достаточным объемом оперативной памяти. Каждая современная операционная система кэширует файлы после первого чтения и получает их из памяти. Вы можете избежать промежуточных файлов путем соединения или хранения их в RAM-диске. Таким образом, препроцессорная работа - это просто конкатенация файлов в большинстве случаев. Это быстро. В реальном времени проводится сбор и компоновка.

Таким образом, любое серьезное приложение, имеющее тысячи файлов, будет огромным. Пример реального мира - мы работаем с приложением, где исходный код содержит более 100 МБ данных (без использования системы и сторонних разработчиков). Таким образом, ваша система должна будет работать с приблизительно 150 МБ-файлом. Я не удивлюсь, если некоторые компиляторы откажутся его скомпилировать. Не говоря уже о времени для компиляции. Лучше разбить на более мелкие файлы и скомпилировать их параллельно. Снова реальный пример - компиляция с одним потоком заняла 40 минут, чтобы закончить, работая на одном сервере с 16 потоками около 2,5-3 минут и компилируя на ферме 16 серверов, каждый из 16 ядер с distcc 30 секунд плюс некоторое время для ссылки.

Другое преимущество создания единства, которое лучше оптимизирует, исчезает при выполнении LTO и статической сборки.

Отвечая на ваш вопрос - да, вы можете это сделать. Имеет ли это смысл? Сомнительно.

Answer 2

Что вы делаете?

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

Люди потратили много времени и усилий на создание C++, чтобы использовать библиотеки и т. Д., Чтобы ускорить компиляцию. О, кстати, система, на которую я смотрю сегодня, имеет 17 миллионов + строк кода. Вы хотите, чтобы это было в одном файле?

Ссылки, предоставленные OP в комментариях, являются хорошим объяснением. Большая проблема, которую я вижу, - это масштабируемость. Это напоминало мне одну область в моей (унаследованной) базе кода, где охранники находятся за пределами включений, чтобы не открывать файлы. например

#ifndef BLAH_H 
#include <blah.h> 
#endif