Les entreprises ne mettent pas VS à niveau comme bon leur semble. Nous utilisons 2010SP1 par exemple sur un projet qui ne prévoit pas d'être expédié avant plusieurs années. Utiliser une version plus récente signifierait acheter de nouvelles licences pour l'IDE, la possibilité d'acheter de nouvelles licences pour les plugins que nous utilisons, et bien sûr de risquer des bugs qui n'ont pas été résolus. Nous avons déjà payé pour 2010 et savons que 2010 répondra à nos besoins.
J'avoue que cela m'agace parfois; J'aimerais vraiment le plus récent support C ++ 11/14, le support AMP et des optimisations améliorées, mais ce genre de mentalité de "mise à niveau vers le nouveau brillant" ne correspond pas bien avec des projets plus grands et plus sérieux.
La plupart des entreprises sont très, très conservatrices quant à la mise à jour de tout logiciel, que ce soit Visual Studio, Office, Windows, Perforce, peu importe. Alors que l'utilisation de Visual Studio 2005 est assez rare pour les jeux aujourd'hui, 2008 est encore assez courante. Très très peu utilisent 2012. Il est fort possible que l'adoption de 2012 ne se produise jamais en masse et que la prochaine version populaire de Visual Studio soit 2013 ou 2014.
Voyez, par exemple, la rapidité avec laquelle la distribution Linux orientée passionné met à jour les versions par rapport à la cadence de sortie de Redhat Enterprise ou Ubuntu LTS. Les utilisateurs à domicile et les hobbiest peuvent plus facilement justifier les mises à niveau et les amateurs les réclament souvent, mais les entreprises veulent généralement le moins de changements possible.
Un autre facteur aujourd'hui est la compatibilité XBox 360. Il est idiot d'acheter et d'installer deux versions de l'IDE / compilateur si vous en avez besoin en particulier pour la compatibilité XBox. La prochaine version de VS qui deviendra populaire pour les jeux dépendra en grande partie du compilateur que la XBox One recommande pour les versions de sortie de ses devkits (2012 est utilisé pour les devkits bêta utilisés pour les jeux de lancement, mais 2013 pourrait être recommandé sur la route pour le post- lancer des titres).
En termes de temps d'exécution utilisés par les compilateurs, ceux-ci doivent correspondre exactement au compilateur utilisé. Cela est dû en partie au fonctionnement de C et C ++. Les interfaces sont définies par des fichiers d'en-tête, qui ne sont en fait qu'un moyen sophistiqué de couper-coller. Considérez la pièce A:
void foo(char* name, int length);
Et considérons maintenant la pièce B:
void foo(int length, char* name);
Si ces fonctions C étaient incluses dans deux versions différentes des runtimes, elles ont toutes les deux un symbole _foomais le code compilé pour utiliser l'une ne fonctionnerait clairement pas pour l'autre. Bien que les problèmes de compatibilité soient généralement un peu plus compliqués et subtils, le résultat final est toujours le même: le code compilé avec VS2005 aura un en-tête de VS2005 qui ne décrit que le fonctionnement du runtime VS2005. VS2012 est livré avec des en-têtes entièrement différents ciblant un runtime entièrement différent.
Microsoft ne prend pas en charge le ciblage des versions antérieures, car cela ne serait vraiment qu'une douleur. Ils devraient expédier puis continuer à conserver les anciens en-têtes en plus des temps d'exécution. Il y a relativement peu de raisons à cela, car les bonnes pratiques d'utilisation des DLL dans Windows permettent aux développeurs de mélanger des bibliothèques à l'aide de différents temps d'exécution. Si vous avez VS2012, vous pouvez toujours créer un lien avec les bibliothèques créées avec VS2005, tant que vous et la bibliothèque suivez quelques règles simples.
Des plates-formes comme GNU / Linux s'efforcent d'éviter ces problèmes, mais les ont traversées, parfois à un niveau beaucoup plus profond. Je me souviens encore de la transition de libc5 à glibc, ou des fréquentes ruptures libstdc ++ de l'époque (c'est l'une des raisons pour lesquelles les développeurs Linux / UNIX sont restés relativement froids sur le sujet de C ++ au fil des ans).
Windows est livré avec un runtime C "générique" de bas niveau appelé MSVCR.DLL, bien que chaque version du compilateur inclue son propre remplacement, par exemple MSVCRR110.DLL. Vous pouvez vous efforcer d'utiliser uniquement la version générique, mais il manque beaucoup de fonctionnalités, y compris la plupart des routines de prise en charge C ++ qui changent avec chaque version de Visual Studio (et sa prise en charge en constante évolution de C ++). Cela ne vaut généralement pas l'effort et les fonctionnalités perdues, sauf si vous essayez vraiment de créer une application sans dépendance (les outils de récupération, les outils du système d'exploitation, les outils de sécurité, etc., tombent parfois dans cette classe).
En bref, chaque Visual Studio possède sa propre bibliothèque d'exécution et l'application compilée avec cette version doit utiliser. Les jeux seront généralement écrits en utilisant moins que le compilateur le plus avancé et nécessiteront donc un runtime plus ancien.