Intentaré responder a su pregunta, aunque es una pregunta antigua, y no parece muy importante (realmente no es muy importante en sí misma ), y ya ha recibido respuestas bastante buenas. La razón por la que quiero responder es que se relaciona con cuestiones fundamentales de la evolución estándar y el diseño del lenguaje cuando el lenguaje se basa en un lenguaje existente: ¿ cuándo se deben desaprobar, eliminar o cambiar las características del lenguaje de formas incompatibles?
En C ++ es posible utilizar la palabra clave estática dentro de una unidad de traducción para afectar la visibilidad de un símbolo (ya sea una variable o declaración de función).
El vínculo en realidad.
En n3092, esto quedó en desuso:
La obsolescencia indica:
- La intención de eliminar alguna característica en el futuro; esto no significa que las características obsoletas se eliminarán en la próxima revisión estándar, o que deban eliminarse "pronto", o en absoluto. Y las funciones no obsoletas pueden eliminarse en la próxima revisión estándar.
- Un intento formal de desalentar su uso .
El último punto es importante. Aunque nunca hay una promesa formal de que su programa no se romperá, a veces silenciosamente, por el siguiente estándar, el comité debe tratar de evitar romper el código "razonable". La obsolescencia debería indicar a los programadores que no es razonable depender de alguna característica .
Sin embargo, subraya que por compatibilidad con C (y la capacidad de compilar programas C como C ++), la desaprobación es molesta. Sin embargo, compilar un programa C directamente como C ++ ya puede ser una experiencia frustrante, por lo que no estoy seguro de si merece consideración.
Es muy importante conservar un subconjunto común de C / C ++, especialmente para los archivos de encabezado. Por supuesto, staticlas declaraciones globales son declaraciones de símbolo con enlace interno y esto no es muy útil en un archivo de encabezado.
Pero el problema nunca es solo la compatibilidad con C, es la compatibilidad con C ++ existente: hay toneladas de programas C ++ válidos existentes que usan staticdeclaraciones globales. Este código no solo es formalmente legal, es sólido, ya que utiliza una característica de lenguaje bien definida de la forma en que está destinado a ser utilizado .
El hecho de que ahora haya una "mejor manera" (según algunos) de hacer algo no significa que los programas escritos a la antigua sean "malos" o "irrazonables". La capacidad de usar la staticpalabra clave en declaraciones de objetos y funciones en el ámbito global se comprende bien en las comunidades C y C ++, y la mayoría de las veces se usa correctamente.
En una línea similar, no voy a cambiar los moldes de estilo C doublea static_cast<double>solo porque "los moldes de estilo C son malos", ya que static_cast<double>agrega cero información y cero seguridad.
La idea de que cada vez que se inventa una nueva forma de hacer algo, todos los programadores se apresuran a reescribir su código de trabajo existente bien definido es una locura. Si desea eliminar todos los problemas y la fealdad heredados, no cambia C ++, sino que inventa un nuevo lenguaje de programación. La eliminación de la mitad de un uso de staticapenas hace que C ++ sea menos C-feo.
Los cambios de código necesitan una justificación, y "lo antiguo es malo" nunca es una justificación para los cambios de código.
Romper los cambios de lenguaje necesita una justificación muy sólida. Hacer el lenguaje un poco más simple nunca es una justificación para un cambio radical.
Las razones dadas por las que statices malo son simplemente notablemente débiles, y ni siquiera está claro por qué no tanto los objetos como las declaraciones de funciones están desaprobados juntos; darles un tratamiento diferente difícilmente hace que C ++ sea más simple o más ortogonal.
Entonces, realmente, es una historia triste. No por las consecuencias prácticas que tuvo: tuvo exactamente cero consecuencias prácticas. Pero porque muestra una clara falta de sentido común por parte del comité de ISO.