Nous sommes actuellement occupés à migrer de Visual Studio 2005 à Visual Studio 2010 (en utilisant C / C ++ non géré). Cela signifie que environ la moitié de nos développeurs utilisent déjà Visual Studio 2010, tandis que l'autre moitié utilise toujours Visual Studio 2005. Récemment, je suis entré dans une situation où une certaine construction peut être écrite de manière propre dans Visual Studio 2010, mais nécessite un 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 celui-ci:
#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
4 Réponses :
J'utiliserais simplement un préprocesseur défini comme Vérification si la date de compilation est plus tard que #Ifdef warn_old_compat . Avec le courrier différé, vous vous souviendrez alors de vous de définir cela.
Pourquoi ne pas simplement faire le chèque au moment de l'exécution de Dev construction? Vous testez sûrement votre code, alors la première fois que quelqu'un le teste après la date, vous obtiendrez la notification.
Je préfère vérifier les choses à la compilation plutôt qu'au moment de l'exécution.
Comme moi, mais dans ce cas, il n'y a pas de mal à vérifier au moment de l'exécution.
dans le cas de GNU CFLAGS + = -DCurdate = $ (date shell +% y% m% d) p> Il ajoutera une macro donc dans la source que vous pouvez faire quelque chose comme ceci: p> faire code> Je le ferais comme ceci: Curdate code> aux drapeaux compilateur, qui contient l'heure actuelle du format yyyymmdd. P> #if CURDATE > 20101101
#error "Do whatever you have to do"
#endif
Personnellement, je choisirais de ne pas croire que tout le monde migrera réellement à la date prévue. Même si je suis convaincu que cela va se passer, je ne veux pas créer de travail supplémentaire pour quiconque ou les empêcher de travailler, dans le cas où je me trompe.
Si rien d'autre, la construction devrait être reproductible. Et si, en décembre, vous réalisez que vous devez reproduire une construction d'octobre? Vous ne pouvez pas (au moins, pas sans compression de l'horloge sur la machine de construction), car cela ne compilera plus. P>
Alors, je ferais cela: P>
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
Belles arguments. Vous avez certainement un point sur "Les constructions devraient être reproductibles". Je ne suis pas d'accord avec le "code mort ne fait pas mal à quiconque" approche. Code mort peut / va confondre les développeurs. Récemment, nous avons eu un problème avec une personne morte du code mort pour le faire fonctionner avec des modifications de la structure de données interne. Je pense donc que ce code mort doit être supprimé (bien que le 1er novembre ne soit probablement pas un bon moment). L'idée "Support2005.h" soulève une idée encore meilleure: pourquoi ne pas utiliser / d_support2005 pour définir le symbole _Support2005 et laisser la compilation échouer si ce symbole n'est pas ici, mais le code ancien est toujours.
Assez juste, je suppose que cela serait largement connu dans votre organisation que ce soutien temporaire de 2005 était nécessaire. Si tel est le cas, une fois que ce n'est plus nécessaire, c'est ne devrait pas confondre quelqu'un ou causer des travaux inutiles, parce que quiconque pensant la modifier pourrait plutôt la supprimer. Je conviens que dans le code mort général devrait être supprimé pour les raisons que vous dites.
Et si quelqu'un supprime l'ancien code mais ne supprime pas l'en-tête. La prochaine fois qu'ils verront l'erreur, ils n'auraient aucune idée de ce qui doit être fait, car tout l'ancien code est déjà parti!
Il y a beaucoup de mauvaises choses qui peuvent arriver si une personne élimine la moitié du code. La ligne #include est juste à côté du #if _msc_ver Ligne: Que voulez-vous de plus? Je suppose que vous pourriez remplacer ce test avec l'utilisation de certaines macro, ce qui est ensuite changé en quelque chose qui causerait une défaillance de la compilation. Ensuite, si le code est supprimé, la macro n'est plus utilisée. L'inclusion de l'en-tête redondante ne provoque aucun mal.
On dirait que le nettoyage peut être scripté assez facilement, alors je ne m'empêcherais pas d'insérer des avertissements supplémentaires pour rappeler aux développeurs de supprimer le code redondant.