2011-01-18 2 views
74

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

В n3092, это было устаревшим:

приложение D.2 [depr.static]
Использование статического ключевого слова является устаревшим при объявлении объектов в области видимости пространства имен (см 3.3.6) ,

В версии n3225 это было удалено.

only article I could find несколько неформальный.

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

Кто-нибудь знает, почему это было изменено?

+3

Вы объявляете объекты в области пространства имен в C? –

+0

Хех, thx, нашел, где его взять. Пытался удалить комментарий, но ты избил меня там. –

+0

Вопрос возник из http://stackoverflow.com/questions/4725204/use-of-static-variables-and-functions-in-global-scope/4725237#4725237 –

ответ

62

В C++ Standard Core Language Defect Reports and Accepted Issues, Revision 94 под 1012. Undeprecating статический `они отмечают:

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

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

+0

Спасибо за ссылку, не подумал о том, чтобы консультироваться с дефектами:/ –

+2

Ну, похоже, усталость побудила бы людей использовать неназванные пространства имен, что было бы хорошо. – sbi

+3

@sbi Почему это хорошо? –

10

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

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

+1

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

+2

Извините, я забыл закончить с ироническим смайликом. –

+1

@ Dan: Именно этот ответ говорит: «принятие желаемого за действительное» по аналогичной ошибочной линии мысли. Пространства имен - важная функция, так же как глобальная область действия-статика, хотя и по разным причинам, и даже при том, что они частично перекрываются применимостью. –

23

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

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

Связь на самом деле.

В n3092, это осуждается:

Deprecation указывает:

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

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

Он подчеркивает, что для совместимости с 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++ менее C-уродливым.

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

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

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

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

+3

Как вы сами указываете, точка зрения на то, что это не рекомендуется, является препятствием для его использования. Тем не менее вы не делаете никаких аргументов в пользу того, что обескуражение его использования неверно. Я, конечно, надеюсь, что никто там не поощряет людей использовать статические объявления с пространственным разделением имен над анонимными пространствами имен. Нет, если они специально не нуждаются в перекрестной компиляции C. –

+1

Мне все равно, что люди, использующие глобальную область «статические» или анонимные пространства имен, я не поощряю и не обескураживаю. Я хочу сказать, что если вы действительно хотите препятствовать людям использовать анонимные пространства имен, вы должны дать им хороший аргумент. На практике я считаю, что в большинстве реализаций сущности, объявленные в неназванном пространстве имен, являются символами, экспортированными со случайным именем, что увеличивает таблицу экспорта. Объекты, объявленные как 'static', OTOH, никоим образом не экспортируются. Таким образом, многие люди выбирают на основе этого наблюдения использование 'static'. – curiousguy

+0

«Как вы сами указываете, точка умаления его заключается в том, чтобы препятствовать ее использованию». «Цель обескураживать его использование заключается в том, что он может исчезнуть однажды. Моя точка зрения заключается в том, что пространство имен 'static' не исчезнет никогда, поэтому неправильно осуждать его. «Да, вы не делаете никаких аргументов, что обескураживать его использование неверно.» «Я не видел убедительных аргументов, которые показывают, что использование пространства имен« static »является« неправильным ». Утаивать его просто для того, чтобы препятствовать его использованию, неправильно, потому что никто на самом деле не верит, что он исчезнет, ​​и потому, что он не убеждает людей в том, что использование этого «неправильно». – curiousguy

Смежные вопросы