Чи невикористані включають шкідливі для C / C ++?

Які негативні наслідки невикористаних включає?

Я знаю, що вони призводять до збільшення двійкового розміру (чи вони?), Чи ще?

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

Вони не обов'язково збільшують двійковий розмір, але збільшують час компіляції.

Головна проблема - безлад . Це три основні аспекти, в яких проявляється безлад:

1. Візуальне забруднення; в той час як ви намагаєтеся зрозуміти інші включення, які вам потрібні.

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

3. Непрозорість залежності; оскільки існує більше заголовків для аналізу, важче визначити цикли залежностей у вашому коді. Знання залежностей вашого коду має вирішальне значення, коли ваша кодова база зростає до будь-якого значного рівня, що перевищує рівень любителів.

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

• Будь-які однотонні сигнали, оголошені як зовнішні в заголовку та визначені у вихідному файлі, будуть включені у вашу програму. Це, очевидно, збільшує використання пам'яті і, можливо, сприяє накладним витратам на продуктивність, змушуючи їх частіше отримувати доступ до файлу своєї сторінки (зараз не велика проблема, оскільки одиночні розміри , як правило, мають малий та середній розмір і тому, що більшість людей, яких я знаю, мають 6+ ГБ оперативної пам'яті).

• Час компіляції збільшується, і для великих комерційних проектів, де часто компілюється, це може призвести до втрати грошей. Це може додати лише кілька секунд до вашого загального часу, але помножте це на кілька сотень компіляцій, або, можливо, вам знадобиться протестувати та налагодити, і у вас є величезна втрата часу, що, таким чином, призводить до втрати прибутку.

• Чим більше заголовків у вас, тим більша ймовірність, що у вас може виникнути зіткнення з макросом, який ви визначили у своїй програмі чи іншому заголовку. Цього можна уникнути, якщо правильно використовувати простори імен, але все одно знайти такі клопоти. Знову втрачена вигода.

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

• Ви можете випадково зв’язати інші зовнішні бібліотеки зі своєю програмою, навіть не підозрюючи про це.

• Ти випадково можеш спричинити кінець світу, роблячи це.

Я припускаю, що всі заголовки можна вважати "щирими", тобто не точно написані з метою саботажу вашого коду.

• Зазвичай це сповільнює компіляцію (попередньо скомпільовані заголовки пом'якшать цей момент)

• це передбачає залежності там, де насправді не існує (це семантичні помилки, а не фактична помилка)

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

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

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

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

• Назви символів C забруднюють ваш код. Оголошення в заголовку забруднюють ваш глобальний або структурний простір імен (і, швидше за все, і те, і інше, оскільки структури зазвичай визначаються типом для введення свого типу в глобальний простір імен). Це пом'якшується за допомогою бібліотек, які додають символи до якогось "імені простору імен", як SDL_CreateMutexдля SDL.

• неіменні імена символів C ++ забруднюють ваш код. З тих самих причин вище. Те саме стосується заголовків, які неправильно використовуютьusing namespaceвисловлювання. Тепер правильний код C ++ буде простором імен його символи. Так, це означає, що зазвичай вам не слід довіряти заголовку C ++, який оголошує його символи в глобальному просторі імен ...

Чи збільшать вони двійковий розмір чи ні, насправді залежить від того, що в них є.

Основним побічним ефектом є, мабуть, негативний вплив на швидкість компіляції. Знову ж таки, наскільки великий вплив залежить від того, що в них є, наскільки і чи включають вони інші заголовки.

Ну а для одного, хто залишає їх там, лише продовжують час компіляції і додають непотрібні залежності компіляції.

Вони представляють незграбний дизайн.

Якщо ви не впевнені, що включити, а що не, це показує, що розробник не уявляв, що робить.

Включити файли передбачається включати лише тоді, коли це потрібно. Можливо, це не така велика проблема, оскільки пам’ять комп’ютера та швидкість зростають різкими темпами в наші дні, але колись, можливо, це було.

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

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

Напр. якщо ви пишете власний клас auto_ptr {}, не включаючи "пам'ять", він буде працювати нормально. але кожного разу, коли ви будете включати пам'ять, компілятор видає помилку, оскільки це вже було оголошено у файлі заголовка пам'яті

Так, вони можуть збільшити двійковий розмір через зовнішні невикористані змінні.

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

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