В конечном счете, единственный способ убедиться, что связаны только те функции, которые вам нужны, состоит в том, чтобы каждый исходный файл (объект) в библиотеке экспортировал только один символ функции - одну (видимую) функцию на файл.Как правило, есть некоторые файлы, которые экспортируют несколько функций, которые всегда все используются вместе - например, функции инициализации и финализации для пакета.Кроме того, часто есть функции, используемые экспортируемой функцией, которые не должны быть видны вне файла источника (объекта) - убедитесь, что они static.
Если вы смотрели на Plauger's * Стандартная библиотека C", вы обнаружите, что каждая функция реализована в отдельном файле, даже если длина файла составляет 4 строки (один заголовок, одна строка функции, открытая скобка, одна строка кода изакрой скобку).
Джей спросил:
В случае большого проекта, не станет ли трудно управлять таким количеством файлов?Кроме того, я не нахожу много проектов с открытым исходным кодом, следующих этой модели.OpenSSL является одним из примеров.
Я не говорил, что он широко использовался - это не так.Но это способ убедиться, что двоичные файлы сведены к минимуму.Компилятор (компоновщик) не сделает минимизацию за вас - по крайней мере, я не знаю ни одного, что делает.В большом проекте вы проектируете исходные файлы так, чтобы тесно связанные функции, которые обычно все будут использоваться вместе, группировались в единые исходные файлы.Функции, которые используются только изредка, должны быть помещены в отдельные файлы.В идеале, редко используемые функции должны быть в отдельном файле;если это не удалось, сгруппируйте их в небольшие (но не минимальные) файлы.Таким образом, если используется одна из редко используемых функций, вы получаете только ограниченное количество дополнительного неиспользуемого кода, связанного.
Что касается количества файлов - да, используемая методика действительно означает много файлов.Вы должны взвесить нагрузку, связанную с управлением (именованием) большого количества файлов, с преимуществами минимального размера кода.Автоматические системы сборки снимают большую часть боли;Системы VCS обрабатывают множество файлов.
Другой альтернативой является помещение кода библиотеки в общий объект - или динамически подключаемую библиотеку (DLL).Затем программы связываются с общим объектом, который загружается в память только один раз и распределяется между программами, использующими его.(Непостоянные) данные реплицируются для каждого процесса.Это уменьшает размер программ на диске за счет исправлений в процессе загрузки.Однако вам не нужно беспокоиться о размере исполняемого файла;исполняемые файлы не включают общие объекты.И вы можете обновить библиотеку (если вы осторожны), не перекомпилировав основные программы, которые ее используют.Уменьшенный размер исполняемых файлов - одна из причин популярности разделяемых библиотек.