Устаревшее статическое ключевое слово... не более?

Ответ 1

В Отчеты и принятые ошибки стандартного основного языка С++, версия 94 под 1012. Undeprecating static. Они отмечают:

Хотя в 7.3.1.1 [namespace.unnamed] указано, что использование статического ключевого слова для объявления переменных в пространстве пространства имен устарело, поскольку неназванное пространство имен обеспечивает превосходную альтернативу, маловероятно, что функция будет удалена в любой момент в обозримом будущем.

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

Ответ 2

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

В С++ можно использовать статическое ключевое слово внутри единицы перевода, чтобы влиять на видимость символа (объявления переменной или функции).

Фактически связь.

В n3092 это устарело:

Отклонение указывает:

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

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

Однако он подчеркивает, что для совместимости с C (и возможностью компиляции C-программ как С++) усталость раздражает. Однако компиляция C-программы непосредственно как С++ может быть разочаровывающим опытом, поэтому я не уверен, что это требует рассмотрения.

Очень важно сохранить общее подмножество C/С++, особенно для файлов заголовков. Конечно, static глобальные объявления являются декларациями символа с внутренней связью, и это не очень полезно в файле заголовка.

Но проблема заключается не в совместимости с C, а в совместимости с существующим С++: существует множество существующих действительных программ на С++, которые используют глобальные объявления static. Этот код не просто формально легален, он звучит, поскольку он использует четко определенную языковую функцию так, как он предназначен для использования.

Просто потому, что теперь есть "лучший способ" (по мнению некоторых) сделать что-то, не делает программы написанными по-старому "плохими" или "необоснованными". Возможность использования ключевого слова static при объявлениях объектов и функций в глобальной области видимости хорошо понимается как в сообществах C, так и в С++ и наиболее часто используется правильно.

В том же духе я не собираюсь менять приведения C-стиля на double до static_cast<double> только потому, что "C-style casts are bad", поскольку static_cast<double> добавляет нулевую информацию и нулевую безопасность.

Идея о том, что всякий раз, когда изобретается новый способ сделать что-то, все программисты спешат переписать свой существующий четко определенный рабочий код, просто сумасшедший. Если вы хотите удалить все унаследованные проблемы и проблемы, вы не меняете С++, вы изобретаете новый язык программирования. Полу удаляющее одно использование static вряд ли делает С++ менее C-уродливым.

Изменения кода нуждаются в оправдании, а "старый - плохой" никогда не является оправданием для изменений кода.

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

Причины, почему static являются плохими, просто замечательно слабы, и неясно даже, почему не оба объекта и объявления функций не устарели вместе - предоставление им разных методов лечения вряд ли делает С++ более простым или более ортогональным.

Итак, действительно, это печальная история. Не из-за практических последствий, которые он имел: он имел ровно нулевые практические последствия. Но поскольку это свидетельствует о явном отсутствии здравого смысла в комитете ИСО.

Ответ 3

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

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