Как убедиться, что неиспользуемые символы не связаны с окончательным исполняемым файлом?

В конечном счете, единственный способ убедиться, что связаны только те функции, которые вам нужны, — это гарантировать, что каждый исходный (объектный) файл в библиотеке экспортирует только один символ функции — одну (видимую) функцию на файл. Как правило, есть файлы, которые экспортируют несколько функций, которые всегда используются вместе — например, функции инициализации и завершения для пакета. Кроме того, часто есть функции, используемые экспортируемой функцией, которые не должны быть видны за пределами исходного (объектного) файла — убедитесь, что они static.

Если вы посмотрите на "Стандартную библиотеку C от Plauger ", вы обнаружите, что каждая функция реализована в отдельном файле, даже если файл состоит из 4 строк (один заголовок, одна функциональная строка, открывающая фигурная скобка, одна строка кода и закрывающая скобка).

Джей спросил:

В случае большого проекта не становится ли сложно управлять таким количеством файлов? Кроме того, я не нахожу много проектов с открытым исходным кодом, следующих этой модели. OpenSSL является одним из примеров.

Я не говорил, что это широко используется - это не так. Но это способ убедиться, что двоичные файлы сведены к минимуму. Компилятор (компоновщик) не будет выполнять минимизацию за вас - по крайней мере, я не знаю ни одного, кто бы это делал. В большом проекте вы проектируете исходные файлы таким образом, чтобы тесно связанные функции, которые обычно используются вместе, были сгруппированы в отдельные исходные файлы. Функции, которые используются лишь изредка, должны быть помещены в отдельные файлы. В идеале каждая редко используемая функция должна находиться в отдельном файле; в противном случае сгруппируйте небольшое их количество в небольшие (но не минимальные) файлы. Таким образом, если используется одна из редко используемых функций, вы получаете только ограниченное количество лишнего неиспользуемого связанного кода.

Что касается количества файлов - да, поддерживаемая методика означает большое количество файлов. Вы должны взвесить рабочую нагрузку по управлению (именованию) большого количества файлов с преимуществом минимального размера кода. Автоматические системы сборки устраняют большую часть боли; Системы VCS обрабатывают множество файлов.

Другой альтернативой является размещение кода библиотеки в общем объекте или в динамической библиотеке ссылок (DLL). Затем программы связываются с общим объектом, который загружается в память только один раз и совместно используется программами, использующими его. (Непостоянные) данные реплицируются для каждого процесса. Это уменьшает размер программ на диске за счет исправлений в процессе загрузки. Однако тогда вам не нужно беспокоиться о размере исполняемого файла; исполняемые файлы не включают общие объекты. И вы можете обновить библиотеку (если вы будете осторожны) без перекомпиляции основных программ, которые ее используют. Уменьшенный размер исполняемых файлов — одна из причин популярности разделяемых библиотек.