Не используются ли вредоносные в C/С++?

Ответ 1

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

Ответ 2

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

Ответ 3

Основная проблема - беспорядок. Это три основных аспекта, в которых проявляется беспорядок:

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

• Логическое загрязнение; у него больше вероятность столкновения функций, больше времени для компиляции (это может быть очень мало для пары включений, но если это станет "политикой", чтобы не очищать ненужные, это может стать значительным препятствием).

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

Ответ 4

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

• Любые сингллеты, объявленные как внешние в заголовке и определенные в исходном файле, будут включены в вашу программу. Это, очевидно, увеличивает использование памяти и, возможно, способствует повышению производительности, заставляя пользователя чаще обращаться к своему файлу страницы (сейчас это не большая проблема, поскольку одиночные игры обычно имеют малый и средний размер, и поскольку большинство людей, которых я знаю, имеют 6+ ГБ ОЗУ).

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

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

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

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

• Вы можете непреднамеренно вызвать конец света, сделав это.

Ответ 5

Я предполагаю, что заголовки могут считаться "искренними", то есть точно не написаны с целью саботирования вашего кода.

• Обычно это замедляет компиляцию (предварительно скомпилированные заголовки уменьшат эту точку)

• он подразумевает зависимости, в которых никого не существует (это семантические ошибки, а не фактическая ошибка)

• макросы будут загрязнять ваш код (смягчается префиксами макросов именами, похожими на имена, как в BOOST_FOREACH вместо FOREACH)

• заголовок может означать ссылку на другую библиотеку. В некотором случае неиспользуемый заголовок может попросить компоновщика связать ваш код с внешней библиотекой (см. MSCV # pragma comment (lib, "" )). Я считаю, что хороший компоновщик не сохранит ссылку на библиотеку, если она не будет использована (ссылка IIRC, MSVC не будет содержать ссылку на неиспользуемую библиотеку).

• удаленный заголовок - это еще один источник неожиданных ошибок., если вы не доверяете заголовку (некоторые кодеры лучше других...), а затем удаление удаляет риск (вам не понравится включение заголовка, изменяющего выравнивание структуры всего после него: сгенерированные ошибки... освещающие...).

• объявление переменной заголовка static будет загрязнять ваш код. Каждое объявление статической переменной приведет к объявлению глобальной переменной в вашем скомпилированном источнике.

• Имена символов C будут загрязнять ваш код. Объявления в заголовке будут загрязнять ваше глобальное или структурное пространство имен (и, скорее всего, они оба, поскольку структуры обычно типизированы для приведения их введите в глобальное пространство имен). Это смягчается библиотеками, префиксными их символами с каким-то "именем пространства имен", например SDL_CreateMutex для SDL.

• имена, не содержащие имен Символы С++ будут загрязнять ваш код. По тем же причинам выше. То же самое касается заголовков, которые неправильно используют оператор using namespace. Теперь правильный код С++ будет содержать пробелы в символах. Да, это означает, что вы обычно не должны доверять заголовку С++, объявляющему его символы в глобальном пространстве имен...

Ответ 6

Независимо от того, увеличивают ли бинарный размер, действительно зависит от того, что в них.

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

Ответ 7

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

Ответ 8

Они представляют собой неуклюжий дизайн.

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

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

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

Ответ 9

include означает, что вы добавляете еще несколько объявлений. Поэтому, когда вы пишете свою собственную глобальную функцию, вам нужно быть осторожным, если эта функция уже объявлена ​​в включенном заголовке.

Ex. если вы напишете свой собственный класс auto_ptr {} без включения "памяти", он будет работать нормально. но всякий раз, когда вы включаете память, компилятор дает ошибку, поскольку она уже объявлена ​​в заголовочном файле памяти

Ответ 10

Да, они могут увеличить двоичный размер из-за внешних неиспользуемых переменных.

//---- in unused includes ----
extern int /* or a big class */ unused_var;

//---- in third party library ----
int unused_var = 13;