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