Я постараюсь ответить на ваш вопрос, хотя это старый вопрос, и он не выглядит очень важным (действительно, не очень важным сам по себе ), и на него уже есть неплохие ответы. Причина, по которой я хочу ответить на этот вопрос, заключается в том, что это относится к фундаментальным вопросам стандартной эволюции и проектирования языка, когда язык основан на существующем языке: когда функции языка должны быть устаревшими, удалены или изменены несовместимыми способами?
В C ++ можно использовать ключевое слово static в единице перевода, чтобы повлиять на видимость символа (объявление переменной или функции).
Фактически связь.
В 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 ++ менее C-уродливым.
Изменения кода требуют обоснования, и «старое - плохо» никогда не является оправданием для изменений кода.
Прекращение языковых изменений требует очень веского обоснования. Слегка упрощение языка никогда не является оправданием серьезного изменения.
Приведенные причины, почему staticэто плохо, просто удивительно слабы, и даже неясно, почему не объявляются устаревшими одновременно и объекты, и объявления функций - разное обращение с ними вряд ли сделает C ++ более простым или более ортогональным.
Так что, действительно, это печальная история. Не из-за практических последствий: у него было ровно ноль практических последствий. Но потому, что это показывает явное отсутствие здравого смысла со стороны комитета ISO.