Est-il possible d'avoir le code source qui « » fois sur (invalide après devient un certain moment)?

Question

Nous sommes en train de migrer occupé à partir de Visual Studio 2005 à Visual Studio 2010 (en C / C ++ non géré). Cela signifie que près de la moitié de nos développeurs utilisent déjà Visual Studio 2010, tandis que l'autre moitié est encore en utilisant Visual Studio 2005. Récemment, je suis tombé dans une situation où une certaine construction peut être écrit de manière propre dans Visual Studio 2010, mais exige le code source moins propre dans Visual studio 2005. Parce que tous les développeurs ont déjà Visual studio 2010 sur leur machine, je dois écrire le code comme ceci:

#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

Étant donné que tous les développeurs migreront vers Visual Studio 2010 d'ici la fin de cette année, je veux ce code pour « disparaître » automatiquement après un certain moment. Garder la « version moins propre » dans les résultats du code source dans le code source illisible à long terme.

Bien sûr, je sais que le code ne disparaît pas automatiquement, donc je veux en fait une sonnette d'alarme automatique après un certain moment. Quelque chose comme ceci:

#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 cette façon, si nous oublions cela, nous sommes informés automatiquement de ce après le 1er novembre 2010.

Cette astuce nécessite probablement l'utilisation de DATE , mais étant donné que ce doit être manipulé par le précompilateur, vous ne pouvez pas effectuer string-manipulations ou utiliser les fonctions date C / heure.

J'ai également considéré l'idée alternative de me simplement envoyer un courrier retardé, mais je me demandais s'il n'y avait pas dans le code source d'une solution qui pourrait être construit.

Answer 1

Personnellement, je choisirais de ne pas croire que tout le monde va migrer en fait à la date prévue. Même si je suis convaincu que ça va se passer, je ne veux pas créer un travail supplémentaire pour quiconque, ou cesser de les travailler, dans le cas où je me trompe.

Si rien d'autre, construit devrait être reproductible. Et si, en Décembre, vous vous rendez compte que vous devez reproduire une version d'Octobre? Vous ne pouvez pas (au moins, non sans bodging l'horloge sur la machine de construction), car il ne sera pas compilé plus.

Alors, je ferais ceci:

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

Une fois que tout le monde a VS 2010, le changement support2005.h pour contenir #error "Remove Visual Studio 2005 compatibility code from this file".

En fait, je ne vérifierait pas personnellement ce changement, car il empêchera quiconque de faire des travaux jusqu'à ce que le soutien VS 2005 est supprimée. Est la suppression du code mort vraiment la tâche la plus haute priorité de votre entreprise pourrait éventuellement avoir le matin du 1er Novembre? Et-t-il besoin de toutes les mains sur le pont pour le faire? Au contraire, je voudrais vérifier, supprimer le fichier, faire une génération complète, gardez la suppression du code de compatibilité jusqu'à ce que tout rebâtis, et vérifier la chose en tant que « retirer le support VS 2005 ».

Vous dites que vous êtes inquiet, vous pourriez oublier, mais si vous le faites, alors quoi? Le code mort ne blesse personne. Vous vous rappellerez la prochaine fois que vous regardez un de ces fichiers, ou la prochaine fois que vous voyez « support2005.h » dans une liste de fichiers, en-tête graphique de dépendance, etc. Donc, ce n'est pas « rendre le code source illisible à long terme », parce que tout le monde à long terme qui voit peut simplement ignorer ou le supprimer. Si vous avez tout type de logiciel d'émission de suivi, vous pouvez trouver la première étape après targetted 2010-11-01, et attacher une tâche à lui, « retirer le support VS 2005, et se débarrasser de support2005.h », avec une note que c'est actuellement bloqué par les développeurs qui utilisent encore VS 2005.

Si vous voulez vraiment 2010-11-01 pour être un délai difficile, après quoi les pauses de code, puis juste rester jusqu'à minuit à l'Halloween, et vérifier dans le changement de rupture alors. Il ne se cassent le code, comme vous avez demandé, mais il ne rompt tous ceux qui rafraichit du contrôle de source, et donc on peut supposer qu'il brise la construction. Plus important encore, il est très facilement réversible, ou peut être supprimée localement, si elle se révèle à quelqu'un d'arrêt pour obtenir du travail fait.

Answer 2

En cas de GNU make je ferais comme ceci:

CFLAGS + = -DCURDATE = $ (date coquille +% Y% m% d)

Il ajoutera une CURDATE macro drapeaux du compilateur, qui contient l'heure actuelle au format AAAAMMJJ.

dans la source que vous pourriez faire quelque chose comme ceci:

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

Pouvez-vous faire quelque chose comme ça dans VS?

Answer 3

Je venais d'utiliser un préprocesseur définir comme #ifdef WARN_OLD_COMPAT. Avec le courrier retardé, vous vous rappeler de définir cela.

Vérifier si la date de compilation est postérieure à est pas possible autrement.

Answer 4

Pourquoi ne pas faire juste le contrôle lors de l'exécution dans dev construit? Certes, vous testez votre code, donc la première fois des tests de quelqu'un après la date, vous aurez la notification.