Каковы отрицательные последствия включения и / или связывания вещей, которые не используются вашим двоичным файлом? - PullRequest
6 голосов
/ 15 апреля 2009

Допустим, у меня есть бинарный файл, который я создаю, и я включаю кучу файлов, которые фактически никогда не используются, и выполняю ли последующие ссылки на библиотеки, описанные этими включаемыми файлами? (опять же, эти библиотеки никогда не используются)

Каковы негативные последствия этого, помимо увеличения времени компиляции?

Ответы [ 13 ]

8 голосов
/ 15 апреля 2009

Некоторые из них, о которых я могу думать, это загрязнение пространства имен и двоичный размер

5 голосов
/ 15 апреля 2009

В дополнение к времени компиляции; Повышенная сложность, ненужное отвлечение внимания при отладке, затраты на обслуживание.

Кроме этого, ничего.

4 голосов
/ 15 апреля 2009

Если библиотеки никогда не используются, размер исполняемого файла не должен увеличиваться.

4 голосов
/ 15 апреля 2009

В дополнение к тому, что перечисляет Саша стоимость обслуживания . Сможете ли вы легко определить, что и что не используется в будущем, когда и если вы решите удалить неиспользуемые вещи?

3 голосов
/ 15 апреля 2009

В зависимости от конкретного компоновщика, вы также можете заметить, что глобальные объекты ваших неиспользуемых библиотек все еще создаются. Это подразумевает нехватку памяти и увеличивает стоимость запуска.

1 голос
/ 15 апреля 2009

Меня раздражает, когда я редактирую файл в дереве исходного кода, потому что в исходном файле появляется какой-то символ, над которым я работаю (например, имя функции, где я только что изменил прототип - или, к сожалению, но больше как правило, просто добавляет прототип в заголовок), поэтому мне нужно проверить правильность использования, или компилятор теперь сообщает мне, что использование в этом файле некорректно. Итак, я редактирую файл. Тогда я вижу проблему - что делает этот файл? И оказывается, что, хотя код «используется» в продукте, он на самом деле не используется вообще.

Я обнаружил возникновение этой проблемы в понедельник. Файл с 10 000+ строками кода вызывал функцию 'extern void add_remainder (void);' с аргументом 0. Итак, я пошел, чтобы исправить это. Затем я посмотрел на остальную часть кода ... оказалось, что это была заглушка разработки около 15 лет назад, которая никогда не была удалена. Чистое удаление кода оказалось незначительным редактированием для более чем полдюжины файлов - и я еще не выяснил, безопасно ли в этом случае удалять константу перечисления из середины перечисления. Временно это помечено как «Не используется / устарел - можно ли его безопасно удалить?».

Этот кусок кода за последние 15 лет имел нулевую зону охвата - производство, тестирование ... Правда, это лишь крошечная часть обширной системы - в процентном отношении это составляет менее 1% диаграмма. Тем не менее, это лишний потраченный впустую код.

Непонятные. Раздражает. Удивительно часто (я зарегистрировал и исправил, по крайней мере, полдюжины подобных ошибок в этом году).

И пустая трата моего времени - и времени других разработчиков. В течение многих лет файл периодически редактировался другими людьми, делающими то, что я делал - тщательная работа.

1 голос
/ 15 апреля 2009

Небольшая компиляция вопросов, вики-редактирование по мере необходимости:

Основная проблема выглядит следующим образом: Загрязнение пространства имен Это может вызвать проблемы при дальнейшей отладке, управлении версиями и увеличении стоимости обслуживания в будущем.

Также будет, как минимум, незначительный Binary Bloat , поскольку ссылки на функции / класс / пространство имен будут поддерживаться (в таблице символов?). Динамические библиотеки не должны сильно увеличивать размер двоичного файла (но они становятся зависимостью для запуска двоичного файла?). Судя по компилятору GNU C, статически связанные библиотеки не должны включаться в окончательный двоичный файл, если на них никогда не ссылаются в исходном коде. (Предположение, основанное на компиляторе C, может потребоваться уточнить / исправить)

Кроме того, в зависимости от природы ваших библиотек, могут создаваться глобальные и статические объекты / переменные, вызывая увеличение времени запуска и нехватку памяти .

Да, и увеличено время компиляции / компоновки.

1 голос
/ 15 апреля 2009

Вы упоминаете об увеличении времени компиляции. Исходя из этого, я понимаю, что библиотеки статически связаны, а не динамически. В этом случае это зависит от того, как компоновщик обрабатывает неиспользуемые функции. Если он игнорирует их, у вас будут в основном проблемы с обслуживанием. Если они будут включены, размер исполняемого файла увеличится. Теперь это более важно, чем место на жестком диске. Большие исполняемые файлы могут работать медленнее из-за проблем с кэшированием. Если активный и неактивный код смежны в exe-файле, они будут кэшироваться вместе, что сделает кэш-память меньше и эффективнее.

VC2005 и выше имеют оптимизацию под названием PGO, которая упорядочивает код в исполняемом файле таким образом, который обеспечивает эффективное кэширование часто используемого кода. Я не знаю, имеет ли g ++ подобную оптимизацию, но стоит посмотреть на это.

1 голос
/ 15 апреля 2009

Здесь - мой ответ на аналогичный вопрос, касающийся C и статических библиотек. Возможно, это будет полезно и вам в контексте C ++.

1 голос
/ 15 апреля 2009

Если библиотеки, которые вы включаете, но не используете, не находятся в целевой системе, он не сможет скомпилироваться, даже если они не нужны.

...