Я спробую відповісти на ваше запитання, хоча це старе питання, і воно виглядає не дуже важливим (воно насправді не дуже важливе саме по собі ), і воно вже отримало досить добрі відповіді. Причиною, на яку я хочу відповісти, є те, що вона стосується фундаментальних питань еволюції стандартів та мовного дизайну, коли мова базується на існуючій мові: коли функції мови слід припиняти, видаляти чи змінювати несумісними способами?
У C ++ можна використовувати статичне ключове слово в одиниці перекладу, щоб впливати на видимість символу (або змінної, або оголошення функції).
Посилання насправді.
У n3092 це було припинено:
Зупинення означає:
- Намір видалити деякі функції в майбутньому; це не означає, що застарілі функції буде видалено під час наступної стандартної версії, або що їх потрібно буде видалити "найближчим часом" або взагалі. А застарілі функції можуть бути вилучені під час наступної стандартної версії.
- Формальна спроба стримувати його використання .
Останній момент важливий. Хоча ніколи не існує офіційних обіцянок, що ваша програма не буде порушена, іноді мовчки, за наступним стандартом, комітет повинен намагатися уникати порушення "розумного" кодексу. Зниження варто повідомляти програмістам, що нерозумно залежати від якоїсь функції .
Однак підкреслюється, що для сумісності з C (і можливості компіляції C-програм як C ++) застарілість дратує. Однак складання програми C безпосередньо як C ++ вже може бути неприємним досвідом, тому я не впевнений, що це вимагає розгляду.
Дуже важливо зберегти загальну підмножину C / C ++, особливо для файлів заголовків. Звичайно, staticглобальні декларації - це декларації символу з внутрішнім зв'язком, і це не дуже корисно у файлі заголовка.
Але проблема ніколи не просто сумісність із C, це сумісність із існуючою C ++: існує безліч діючих діючих програм C ++, які використовують staticглобальні декларації. Цей код не просто формально легальний, він обгрунтований, оскільки використовує чітко визначену мовну функцію так, як його передбачається використовувати .
Те, що зараз існує "кращий спосіб" (на думку деяких) щось робити, не робить програми, написані по-старому, "поганими" або "нерозумними". Можливість використання staticключового слова для декларацій об’єктів та функцій у глобальному масштабі добре зрозуміла як у спільнотах C, так і в C ++, і найчастіше використовується правильно.
Подібним чином я не збираюся змінювати актори в стилі C doubleна static_cast<double>лише тому, що "актори в стилі C погані", оскільки це static_cast<double>додає нульової інформації та нульової безпеки.
Думка про те, що щоразу, коли вигадується новий спосіб щось зробити, всі програмісти поспішають переписувати свій існуючий чітко визначений робочий код, просто божевільна. Якщо ви хочете видалити всі успадковані негаразди та проблеми C, ви не змінюєте C ++, ви винаходите нову мову програмування. Видалення наполовину одного використання staticнавряд чи робить C ++ менш потворним.
Зміни коду потребують обґрунтування, а "старе - це погано" ніколи не є виправданням змін коду.
Порушення мовних змін потребує дуже вагомого обґрунтування. Спрощення мови дещо спрощеніше ніколи не є виправданням непереборних змін.
Наведені причини, чому staticце погано, просто надзвичайно слабкі, і навіть незрозуміло, чому і об'єкти, і оголошення оголошень не застаріли разом - надання їм різної обробки навряд чи робить C ++ простішим або більш ортогональним.
Тож насправді це сумна історія. Не через практичні наслідки, які це мало: це мало рівно нульові практичні наслідки. Але оскільки це свідчить про явну відсутність здорового глузду з боку комітету ISO.