¿La desaprobación se considera dañina? [cerrado]

Acabo de compilar parte de mi propio código con la -std=c++0xbandera en GCC, ya que quiero seguir vagamente con lo que están haciendo todos los jóvenes (siempre que se mantengan fuera de mi césped), y terminé con un montón de advertencias. sobre auto_ptrser desaprobado. Por supuesto, sabía que auto_ptrestaba en desuso en C ++ 0x, pero ...

¿No es la desaprobación una pérdida de tiempo y esfuerzo? Razones para no despreciar (con auto_ptr como ejemplo):

• Hay un océano de código por ahí que aún necesita ser soportado, producir millones de advertencias solo tentará a las personas a desactivarlas.

• auto_ptr es un poco molesto, pero en realidad hace lo que dice en la lata.

• si realmente queremos desaprobar las cosas, las nomino printf(). Pero solo imagine los chillidos que seguirían. auto_ptrno tiene muchos amigos, pero al menos en mi código C ++ se usa más que printf, lo que no se usa en absoluto.

• el comité tiene un mal historial de hacer esto bien: desaprobaron la estática en el ámbito del espacio de nombres, y ahora parece haber quedado desaprobada. No me sorprendería si auto_ptrhiciera un regreso similar

• Por último, independientemente de lo que diga el comité, los implementadores del compilador los ignoran: simplemente no pueden arriesgarse a romper el código de sus clientes, todo lo que pueden hacer es emitir advertencias irritantes.

Entonces, mi pregunta: ¿considera la desaprobación (de cualquier cosa, no solo auto_ptrs, y no solo en C ++) una buena idea, y si es así, ¿por qué?

Motivos de desaprobación (en general):

• Indica claramente a las personas que algo es mala práctica (y con suerte sugiere una alternativa).
• El período de desaprobación brinda a las personas la oportunidad de cambiar su código antes de que el compilador lo elimine por completo.

También estoy en desacuerdo sobre el último punto. Los compiladores no ignoran al comité, y eventualmente eliminan las cosas que están en desuso (por ejemplo, >?=y <?=en GCC, fueron en desuso y luego se eliminaron *).

Creo que el punto importante es: algunas cosas deberían eliminarse, por varias razones, y creo que la desaprobación es la única forma sensata de hacerlo. En este caso específico, auto_ptrdebe eliminarse ya que ha sido reemplazado por unique_ptr. Cambiar es bastante fácil y la gente tendrá mucho tiempo para hacerlo.

(*) Sí, sé que son extensiones y no estándar, pero el punto es que los proveedores de compiladores eventualmente eliminan las cosas una vez que ingresan en desuso, ya sea que el código aún se base en ellas o no.

Cualquier API suficientemente complicada probablemente tendrá fallas que no se descubrirán hasta después de que se hayan usado por un tiempo. Nuestras opciones:

• Deja las cosas como están. Esto significa que la API continuará reuniéndose cada vez más a medida que evoluciona con el tiempo. Incluso si se agregan versiones nuevas y mejoradas, las antiguas también deberán mantenerse mantenidas.
• Eliminarlo sin previo aviso. Es probable que esto rompa mucho código.
• Desaprobarlo y eliminarlo en una versión posterior. Esto da tiempo para arreglar el código existente, al tiempo que garantiza que la cantidad de cruft permanezca limitada.

La desaprobación es la más sensata de estas alternativas.

Nah La desaprobación puede ser algo realmente bueno. Evita que las tecnologías se atasquen con el viejo equipaje inútil.

Solo en el ámbito de C ++, recuerdo la "característica" de Microsoft de no admitir correctamente la declaración de variables dentro de una declaración for. Eso continuó durante aproximadamente una década e hizo una gran cantidad de código no portátil. Esa es una "característica" que me alegra que haya quedado en desuso.

En términos más generales, Apple ha tenido la costumbre desde los años 80 de marcar API viejas y torpes como "obsoletas" durante 5-7 años antes de eliminarlas. Estaba hablando con un ingeniero de Apple en WWDC sobre la depreciación de algunas de las antiguas API de QuickTime C, y me encantó saber que estaban haciendo eso, porque el soporte continuo para un modelo desarrollado alrededor de 1990 estaba obstruyendo por completo lo que uno esperaría poder hacer en las modernas CPU multinúcleo de 64 bits.

En la práctica, tomará mucho tiempo a los escritores de compiladores volcar auto_ptr, y probablemente admitirán algún modo de compatibilidad con versiones anteriores durante una década o dos, pero es algo bueno.

si realmente queremos desaprobar las cosas, nomino printf ()

printfEs una función útil. Permite formatear cosas de manera más corta que los iostreams. Y es una función C. La razón por la que C ++ existe y se usa es porque es compatible con C. Por lo tanto, la degradación printfparece menos útil.

Entonces, ¿alguien más está listo para una cruzada contra la despreciación?

El comité es consciente de algunos de los problemas del supuesto significado actual de desaprobación. Ver el significado de la deprecación .

Los idiomas y las API tienen que avanzar. Aunque puede haber una tonelada de código dependiendo de alguna característica anterior, puede haber una nueva y mejor manera de hacer algo y el costo de soportar la característica anterior es demasiado.

La desaprobación también advierte que en el futuro, la función se eliminará. Esto les da a los desarrolladores tiempo para actualizar su código si se mantienen al día con la nueva API. Esto es mucho mejor que la alternativa: eliminación total. Recuerde que la depreciación es una advertencia, no un error.

Y si este es un programa antiguo que no desea actualizar, entonces nada le impide usar la API anterior (o en este caso el compilador).

Tal como están las cosas, la degradación tiene al menos dos significados.

• Se eliminará en una versión futura
• Creamos mejores alternativas y ahora la función es redundante (pero no completamente inútil). Los recién llegados deberían saltear esto mientras aprenden el idioma; sin embargo, no se eliminará en el corto plazo.

Creo que la estática cae en la última categoría, pero solo el tiempo dirá si auto_ptr realmente merece ser eliminado o si es mejor mantenerlo en el idioma.

La degradación no es perjudicial si se puede pasar a una alternativa en 1 día laboral: por ejemplo. La búsqueda / reemplazo simple de la función anterior con la nueva, o una capa de compatibilidad es fácil de configurar.

Si necesita reescribir grandes partes del software debido a la obsolescencia, entonces es perjudicial.

Un buen ejemplo sería probablemente la API mysql de PHP, básicamente solo necesita reemplazar todos los mysql_ * con mysqli_ * y proporcionarles una identificación de enlace y ya está.

Un mal ejemplo es la eliminación y eliminación de glBegin, glEnd y todo el material de cálculo matricial de OpenGL, si desea que su código funcione en OpenGL3 o superior, deberá reescribir todo el código de renderizado para usar buffers de vértices.

Creo que es una buena manera de hacer saber a la gente que hay una mejor manera. Prefiero una desaprobación agradable en lugar de una función que simplemente desaparece.