Почему многие объектные файлы связаны вместо одного большого объектного файла?
Почему скомпилированные языки программирования (например, C ++) настроены на создание много объектных файлов которые связаны друг с другом, а не один большой объект создается?
Например (написано на C ++, может применяться к любому скомпилированному языку), рассмотрим два файла в проекте main.cpp а также auxiliary.cpp, В чем разница между main.cpp а также auxiliary.cpp компилируется в main.o а также auxiliary.o а затем связано с main.exe, а также main.cpp с #include auxiliary.cpp компилируется только main.o и связано с main.exe? Насколько мне известно, это было бы по крайней мере поверхностно произвести тот же результат.
Я вижу необходимость в нескольких объектах в случае многоязычных проектов, но не иначе. Предоставляет ли несколько объектов компоновщику больше гибкости при создании исполняемого файла?
Решение
Отдельные блоки компиляции, подобные этой, ускоряют компиляцию. Если вы внесете изменения в auxilliary.cpp, компилятору нужно только пересоздать auxilliary.o вместо того, чтобы перекомпилировать все. Это становится особенно важным, чем больше проект.
Другие решения
Я могу ответить на это риторическим вопросом: почему вы пишете много функций вместо одной большой?
Та же логика применяется на уровне ссылок.
Если ты хочешь один большой двоичный файл, вам просто нужно построить статический библиотека, но это не объектный код из одной единицы перевода, а из многих.
Теперь подумайте, действительно ли то, что вы спрашиваете, имеет смысл: если бы он создавал один файл .o, он должен был бы объединить результаты компиляции каждого cpp в этот двоичный файл по мере его построения, эффективно оплачивая стоимость объединения нескольких раз. Кроме того, изменение одного модуля перевода потребовало бы, чтобы компилятор выяснил, какие из символов в файле больших объектов взяты из исходной версии этого модуля перевода, удалил их из объекта и добавил новые после перестроения.