Почему бы явно не включить #include .c файлы?
В программах на C, которые я видел, файлы .h всегда явно включаются, используя:
#include "some_header_file.h"
С другой стороны, файлы .c очень редко включаются с использованием:
#include "some_c_file.c"
Три вопроса:
В чем разница?
Когда вы отойдете от нормы и явно включите файл .c?
Как компоновщик узнает, что в проект включен требуемый файл .c и где его искать?
1) см. Пост от marblixon reply; 2) редко. Обычно связано с использованием определений макросов. 3) компоновщику все равно. он связывает файлы object, на которые вы указываете ссылку. Он не понимает исходные файлы.
Ответы 3
Заголовочные файлы определяют интерфейс (объявления функций, определения макросов, определения типов и т. д.), В то время как файлы .c определяют реализация (определения функций и объектов).
Вы почти никогда не включаете файл .c в другой файл .c, в первую очередь потому, что это быстро становится кошмаром обслуживания, если два файла .c используют одни и те же символы для разных целей или если вы связали включения (a.c включает b.c, который включает c.c, и т. д.), и вы получите единицу перевода, которая слишком велика для компилятора. Это также означает, что если вы измените включенный файл .c, вам придется перекомпилировать все, что его включает, независимо от того, изменился этот код или нет, что делает сборку дольше, чем следовало бы.
РЕДАКТИРОВАТЬ
Третья причина заключается в том, что вы можете захотеть скрыть некоторые элементы данных или функции от более крупной программы (по сути, сделав эти элементы «частными» для определенного исходного файла). Если вы включите этот исходный файл в другой исходный файл, вы потеряете эту возможность. Опять же, это настоящая проблема, если вы используете одно и то же имя переменной или функции для разных целей в разных файлах.
КОНЕЦ РЕДАКТИРОВАНИЯ
Раздельная компиляция и компоновка - это хорошо, особенно в больших проектах.
Линкеры обычно ничего не знают об исходных файлах - в типичной цепочке инструментов программист указывает, где все находится, через make-файл или что-то подобное.
Why the difference?
Придерживаться модульного подхода к проектированию.
When would you divert from the norm and include a .c file explicitly?
В основном никогда.
How does the linker know that a required .c file is included in the project and where to look for it?
Компоновщику нужны не файлы .c, а файлы .o (например), созданные компилятором (в контексте этого вопроса) из файлов .c. Где расположены эти файлы .o, компоновщику сообщает его вызывающий (IDE, makefile, пользователь).
E en больше. Компоновщик не заботится о языке. Вы можете связать объектные файлы, написанные на разных языках.
@P__J__: Я не говорю, что компоновщик заботился о языке. Но я сделаю свой ответ менее многозначительным.
Одна из основных причин не включать .c явно в другие файлы .c - это желание избежать повторяющихся символов.
Рассмотрим файл a.c, который определяет глобальный символ (переменную или функцию) с именами A. Предположим, b.c и c.c # включают файл a.c. Если у вас есть Makefile, который компилирует и связывает b.c и c.c и создает приложение, у вас может произойти сбой компоновщика из-за дублирования определений A:
A A
| |
a.c a.c
| |
b.c c.c
\ /
executable
В этом графе зависимостей исполняемый файл не может быть построен, если A не является символом области видимости файла.
Чтобы избежать этого, можно было бы записать все файлы #include в один «главный» файл, что является очень строгим антипаттерном.
«В этом графе зависимостей не может быть построен исполняемый файл» А с включением файлов .h не возникнет проблем, потому что область видимости всегда локальная?
Если вы следуете соглашению, что символы просто объявляются в файлах .h, а не определены, тогда, это не будет проблемой. Это, конечно, еще одно соглашение, которое C никоим образом не обеспечивает, и есть исключения (например, встроенные функции), которые можно определить в файлах заголовков.
Я думаю, что в сообщении это на некоторые из ваших вопросов есть хорошие ответы.