Obsolescencia de la palabra clave estática… ¿no más?

10 minutos de lectura

Obsolescencia de la palabra clave estatica ¿no mas
Matthieu M.

En C++ es posible usar el static palabra clave dentro de una unidad de traducción para afectar la visibilidad de un símbolo (ya sea variable o declaración de función).

En n3092, esto quedó en desuso:

Anexo D.2 [depr.static]

El uso de la palabra clave estática está en desuso cuando se declaran objetos en el ámbito del espacio de nombres (ver 3.3.6).

En n3225, esto se eliminó.

los único artículo que pude encontrar es algo informal.

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.

¿Alguien sabe por qué se cambió?

  • ¿Declaras objetos en el ámbito del espacio de nombres en C?

    – Étienne de Martel

    18 de enero de 2011 a las 16:44

  • je, gracias, encontré dónde conseguirlo. Intenté eliminar el comentario pero me ganaste allí.

    – Edward Extraño

    18 de enero de 2011 a las 17:10

  • La pregunta surgió de stackoverflow.com/questions/4725204/…

    – Fred Nurk

    18 de enero de 2011 a las 17:28

  • Esto también le da al Comité de C++ la oportunidad de eliminar algo en la próxima versión del Estándar 🙂

    –James McNellis

    10 de febrero de 2011 a las 22:48

  • stackoverflow.com/questions/4422507/…

    – Martín Ba

    4 de julio de 2013 a las 12:07

Obsolescencia de la palabra clave estatica ¿no mas
Johannes Schaub – litb

En Informes de defectos del lenguaje central estándar de C++ y problemas aceptados, revisión 94 bajo 1012. Undeprecating static ellos notan:

Aunque 7.3.1.1 [namespace.unnamed] establece que el uso de la palabra clave estática para declarar variables en el ámbito del espacio de nombres está en desuso porque el espacio de nombres sin nombre proporciona una alternativa superior, es poco probable que la función se elimine en algún momento en el futuro previsible.

Básicamente esto está diciendo que la desaprobación de static realmente no tiene sentido. Nunca se eliminará de C++. Todavía es útil porque no necesita el código repetitivo que necesitaría con unnamed namespace‘s si solo desea declarar una función u objeto con enlace interno.

  • Bueno, parece que la desaprobación alentaría a las personas a usar espacios de nombres sin nombre, lo que sería algo bueno.

    – sbi

    23 de febrero de 2011 a las 16:04

  • @nbt: porque no puede usar símbolos estáticos como argumentos de plantilla y porque muchos novatos encontrarían que los estáticos son más fáciles de usar y luego no tienen la tentación de probar y et al. Sólo un pensamiento rápido.

    – Sebastián Mach

    4 de julio de 2011 a las 13:48


  • “porque no necesita el código repetitivo que necesita con espacios de nombres sin nombre”? ¿Qué “código repetitivo”? Algo más allá”namespace {” y “}“?

    – towi

    25 de febrero de 2014 a las 8:24

  • @towi en comparación con static, hay dos llaves adicionales y en muchos estilos de codificación escribirá al menos 3 líneas de código para sangrar la declaración.

    – Johannes Schaub – litb

    25 de febrero de 2014 a las 10:35

  • Me gusta declarar funciones auxiliares, globales, etc. estáticas y lo más cercanas posible a su uso. la sintaxis del espacio de nombres { } es fea para este propósito, y “estático” está bien. a otras personas les gusta poner todas sus cosas de ayuda en la parte superior de un archivo. la sintaxis del espacio de nombres {} es más útil allí. así que es realmente una cuestión de estilo. ambos son, en última instancia, equivalentes.

    – Erik Aronesty

    15 de enero de 2015 a las 18:13

1646747476 888 Obsolescencia de la palabra clave estatica ¿no mas
chico curioso

Intentaré responder a su pregunta, aunque es una pregunta antigua y no parece muy importante (realmente no es muy importante en si mismo), 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 las características del idioma deben quedar obsoletas, eliminarse o cambiarse de formas incompatibles?

En C++ es posible usar la palabra clave estática dentro de una unidad de traducción para afectar la visibilidad de un símbolo (ya sea variable o declaración de función).

El vínculo en realidad.

En n3092, esto quedó en desuso:

La desaprobación indica:

  • los intención para eliminar alguna característica en el futuro; esto no significa que las funciones en desuso 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.

Este último punto es importante. Aunque nunca hay una promesa formal de que su programa no se romperá, a veces en silencio, por el próximo estándar, el comité debe tratar de evitar romper el código “razonable”. La desaprobación debería decirles 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, static Las 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 static declaraciones globales. Este código no es sólo formalmente legal, es sólido, como utiliza una función 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 hace que los programas escritos de la manera anterior sean “malos” o “irrazonables”. La habilidad de usar el static La palabra clave en declaraciones de objetos y funciones en el ámbito global se entiende bien en las comunidades de C y C++, y se usa correctamente con mayor frecuencia.

De manera similar, no voy a cambiar los moldes de estilo C a double para static_cast<double> solo porque “los moldes de estilo C son malos”, como static_cast<double> añade cero información y cero seguridad.

La idea de que cada vez que se invente una nueva forma de hacer algo, todos los programadores se apresuren a reescribir su código de trabajo bien definido existente es una locura. Si desea eliminar toda la fealdad y los problemas heredados de C, no cambia C++, inventa un nuevo lenguaje de programación. Retirar a la mitad un uso de static difícilmente hace que C++ sea menos C-feo.

Los cambios de código necesitan una justificación, y “lo viejo es malo” nunca es una justificación para los cambios de código.

Romper los cambios de idioma necesita una justificación muy sólida. Hacer que el lenguaje sea un poco más simple nunca es una justificación para un cambio radical.

Las razones dadas por qué static es malo son notablemente débiles, y ni siquiera está claro por qué las declaraciones de objetos y funciones no están en desuso juntas; darles un tratamiento diferente difícilmente hace que C++ sea más simple u ortogonal.

Entonces, realmente, es una historia triste. No por las consecuencias prácticas que tuvo: tuvo exactamente cero consecuencias prácticas. Sino porque muestra una clara falta de sentido común por parte del comité ISO.

  • Como usted mismo señala, el objetivo de desaprobarlo es desalentar su uso. Sin embargo, usted no argumenta que desalentar su uso está mal. Ciertamente espero que nadie anime a las personas a usar declaraciones estáticas con ámbito de espacio de nombres en lugar de espacios de nombres anónimos. No, a menos que necesiten específicamente realizar una compilación cruzada de C.

    – Nicolás Bolas

    10 de diciembre de 2011 a las 22:22

  • No me importa mucho la gente que usa el alcance global static o espacios de nombres anónimos, tampoco estoy alentando ni desalentando. Mi punto es que si realmente quiere disuadir a las personas de usar espacios de nombres anónimos, debe darles un buen argumento. En la práctica, creo que en la mayoría de las implementaciones, las entidades declaradas en un espacio de nombres sin nombre son símbolos exportados con un nombre aleatorio, lo que hace crecer la tabla de exportación. Entidades declaradas como static, OTOH, no se exportan de ninguna manera. Por lo tanto, muchas personas eligen, en base a esa observación, usar static.

    – chico curioso

    11 de diciembre de 2011 a las 23:49

  • Como usted mismo señala, el objetivo de desaprobarlo es desalentar su uso.” El punto de desalentar su uso es que podría desaparecer algún día. Mi punto es que namespace-scope static no desaparecerá nunca, por lo que está mal desaprobarlo. “Sin embargo, usted no argumenta que desalentar su uso está mal.” No he visto ningún argumento convincente que muestre que el uso de namespace-scope static Está Mal”. Desaprobarlo solo para desalentar su uso está mal, porque nadie realmente cree que vaya a desaparecer, y porque no convence a las personas de que usarlo es “incorrecto”.

    – chico curioso

    11 de diciembre de 2011 a las 23:57

  • Ciertamente espero que nadie anime a las personas a usar declaraciones estáticas con ámbito de espacio de nombres en lugar de espacios de nombres anónimos.” Algunas personas piensan que static es mejor y fomentar su uso en espacios de nombres anónimos. Mi punto no es que uno sea mejor que el otro; mi punto es 1) que ninguna característica (static, espacios de nombres anon) es “incorrecto”. 2) que desaprobar una característica útil, bien definida y ampliamente utilizada que no va a funcionar, nunca, está mal. Hacer eso reduce la credibilidad del comité de C++ (y ya es bastante baja).

    – chico curioso

    12 de diciembre de 2011 a las 0:05

  • Todo el lenguaje “desaparecerá algún día”. Dejemos de lado C++.

    – Carreras de ligereza en órbita

    17 de enero de 2013 a las 18:24

Ya sea obsoleta o no, la eliminación de esta función de idioma rompería los códigos existentes y molestaría a las personas.

Todo el asunto de la desaprobación estática fue solo una ilusión en la línea de “los espacios de nombres anónimos son mejores que los estáticos” y “las referencias son mejores indicadores”. Jajaja.

  • ¿”Las referencias son mejores indicadores”? No, los punteros inteligentes son punteros más inteligentes. No puede usar referencias para la memoria asignada desde el montón, err, tienda libre.

    – Dan Breslau

    18 de enero de 2011 a las 17:06


  • Lo siento, olvidé terminarlo con una carita irónica.

    – Máximo Egorushkin

    18 de enero de 2011 a las 17:09

  • @Dan: Eso es exactamente lo que dice esta respuesta: “ilusiones” a lo largo de una línea de pensamiento defectuosa similar. Los espacios de nombres sin nombre son una característica importante, al igual que el alcance global estático, aunque por razones ligeramente diferentes, y aunque tienen cierta superposición en la aplicabilidad.

    – Fred Nurk

    18 de enero de 2011 a las 17:26


  • @Fred, @Maxim: Lo siento si no entendí bien o si tengo fallas en la memoria. Pero no clasifico “las referencias son mejores punteros” como equivalentes a “los espacios de nombres anónimos son mejores que los estáticos” como un caso de ilusión. Soy muy consciente del intento de hacer que este último se mantenga, pero no recuerdo que nadie haya hecho una propuesta seria para reemplazar los punteros con referencias. Una vez más, tal vez sea mi propia conciencia lo que falta.

    – Dan Breslau

    19 de enero de 2011 a las 1:09

  • @DanBreslau: char* foo = new char; char& ref = *foo; El hecho de que inicialmente se le dé un puntero no dice nada sobre su capacidad para usar referencias.

    – Carreras de ligereza en órbita

    4 de febrero de 2012 a las 2:54


¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad