¿Es posible tener el código fuente que 'agote el tiempo' (se vuelve inválido después de cierto momento)?

Question

Actualmente estamos ocupados migrando de Visual Studio 2005 a Visual Studio 2010 (usando C/C++ no administrado). Esto significa que aproximadamente la mitad de nuestros desarrolladores ya están usando Visual Studio 2010, mientras que la otra mitad todavía está usando Visual Studio 2005. Recientemente, llegué a una situación en la que se puede escribir cierta construcción de manera limpia en Visual Studio 2010, pero requiere código fuente menos limpia en Visual Studio 2005. Debido a que no todos los desarrolladores ya han Visual Studio 2010 en su máquina, tengo que escribir el código como el siguiente:

#if _MSC_VER >= 1600 
    // clean version of the source code 
#else 
    // less clean version 
    // of the source code 
    // requiring multiple lines of code 
    // and requiring some dirty static_casts 
#endif 

Dado que todos los desarrolladores va a migrar a Visual Studio 2010; Para finales de este año, quiero que este código 'desaparezca' automáticamente después de cierto momento. Mantener la 'versión menos limpia' en el código fuente da como resultado un código fuente ilegible a largo plazo.

Por supuesto, sé que el código no desaparece automáticamente, por lo que en realidad quiero una alarma automática después de cierto momento. Algo como esto:

#if _MSC_VER >= 1600 
    // clean version of the source code 
#else 
    // less clean version 
    // of the source code 
    // requiring multiple lines of code 
    // and requiring some dirty static_casts 
#endif 
#if compilation_date is after 1 november 2010 
# error "Remove Visual Studio 2005 compatibility code from this file" 
#endif 

De esa manera, si nos olvidamos de esto, se nos notifica automáticamente de esta después del 1 de noviembre de 2010.

Este truco probablemente requiere el uso de FECHA, pero ya que este necesidades para ser manejado por el precompilador, no puede realizar manipulaciones de cadena o usar las funciones de fecha/hora C.

También consideré la idea alternativa de enviarme un correo retrasado, pero me preguntaba si no había una solución que pudiera incluirse en el código fuente.

Answer 1

Personalmente, elegiría no creer que todos migrarán en la fecha prevista. Incluso si estoy seguro de que va a suceder, no quiero crear trabajo adicional para nadie ni dejar de trabajar en caso de que me equivoque.

Si nada más, las compilaciones deberían ser reproducibles. ¿Qué pasa si, en diciembre, te das cuenta de que necesitas reproducir una construcción desde octubre? No se puede (al menos, no sin forzar el reloj en la máquina de compilación), ya que no compilará más.

Por lo tanto, me gustaría hacer esto:

support2005.h 
------------- 

// empty file 

source file 
----------- 

#include "support2005.h" 
#if _MSC_VER >= 1600 
    // clean version of the source code 
#else 
    // less clean version 
    // of the source code 
    // requiring multiple lines of code 
    // and requiring some dirty static_casts 
#endif 

vez que todos hayan VS 2010, el cambio support2005.h para contener #error "Remove Visual Studio 2005 compatibility code from this file".

En realidad yo personalmente no verificaría ese cambio, ya que evitará que alguien haga ningún trabajo hasta que se elimine el soporte de VS 2005. ¿Eliminar realmente el código muerto es la tarea de mayor prioridad que su empresa podría tener en la mañana del 1 de noviembre? ¿Y requiere todas las manos en cubierta para hacer eso? Por el contrario, debería verificar, eliminar el archivo, hacer una compilación completa, seguir eliminando el código de compatibilidad hasta que todo vuelva a compilarse, y verificar todo como "eliminar el soporte de VS 2005".

Dices que te preocupa que puedas olvidar, pero si lo haces, ¿y qué? El código muerto no está lastimando a nadie. Lo recordarás la próxima vez que veas alguno de esos archivos, o la próxima vez que veas "support2005.h" en una lista de archivos, gráfico de dependencia del encabezado, etc. Así que no es "hacer que el código fuente sea ilegible a largo plazo" ", porque a largo plazo cualquiera que lo vea puede simplemente ignorarlo o eliminarlo. Si tiene algún tipo de software de seguimiento de problemas, puede encontrar el primer objetivo designado después de 2010-11-01 y adjuntarle una tarea, "eliminar el soporte de VS 2005 y deshacerse de support2005.h", con una nota. que actualmente está bloqueado por desarrolladores que todavía usan VS 2005.

Si realmente quiere que 2010-11-01 sea una fecha límite difícil, después de lo cual se rompe el código, simplemente quédese hasta la medianoche en Halloween y controle el rompiendo el cambio entonces. En realidad, no rompe el código, como solicitó, pero rompe a cualquiera que se actualice desde el control de código fuente y, por lo tanto, presumiblemente rompe la compilación. Lo que es más importante, es muy fácilmente reversible, o puede ser suprimido localmente, si resulta que impide que alguien haga el trabajo.

Answer 2

Solo usaría un preprocesador definir como #ifdef WARN_OLD_COMPAT. Con el correo retrasado, usted recordará que debe definir esto.

Comprobando si la fecha de compilación es posterior a <X> no es posible de otras maneras.

Answer 3

¿Por qué no hacer el control en tiempo de ejecución en compilaciones de desarrollo? Seguramente prueba su código, por lo que la primera vez que alguien lo pruebe después de la fecha, recibirá la notificación.

Answer 4

En caso de GNU make lo haría así:

CFLAGS + = -DCURDATE = $ (fecha shell +% Y% m% d)

se agregará una macro CURDATE a indicadores del compilador, que contiene la hora actual en formato YYYYMMDD.

Así que en origen se podría hacer algo como esto:

#if CURDATE > 20101101 
#error "Do whatever you have to do" 
#endif 

¿Se puede hacer algo como esto en VS?