VS 2005 : La revanche des C++iens
Je viens d’assister à la rencontre C++ organisé par Microsoft. Pour une fois tous les intervenants venaient de Microsoft (dont les fameux Eric Mittelette et Eric Vernié), voire même de Redmond (ce qui nous a valu quelques gags lors de la traduction simultanée improvisée).
Je ne vais pas faire un compte rendu détaillé, d’autant que la plupart des démos sont disponibles ici.
Je note avec plaisir que Microsoft a décidé avec Visual Studio 2005 de réinvestir sur Visual C++ qui en sera à sa version 8.0, selon deux axes :
- Visual C++ 8.0 reste le langage de choix pour le code natif Win32 et supporte mieux la norme C++ 98 (98 % de la norme).
- Visual C++ 8.0 devient un langage managé crédible, avec une syntaxe plus lisible que dans les version 7.0 et 7.1 (VS 2002 et 2003), et le langage de choix pour le mélange de code managé et natif.
Parmi les améliorations intéressantes, j’ai surtout retenu :
- Une amélioration de la protection contre les débordement de tampon par rapport à VS2003 et l’ajout d’une CRT sécurisé.
- L’optimisation globale fonctionne aussi pour le code managé (voir la démo).
- Une optimisation après instrumentation du code apparaît (adieu le compilateur et le profiler Intel).
- Le support de Open MP pour l’écriture d’applications multithread (hyperthreading et multi-coeur oblige). On en parle ici.
- Une analyse statique du code lors de la compilation pour détecter les erreurs fréquentes. Le retour de lint !
- Une navigation facile dans les classes et les dépendances sans devoir compiler le source.
- Une proposition d’extension du C++ (C++/CLI) normalisé pour rendre C++ compatible avec certaines constructions propre à la CLI .Net.
- Le support 64 bits, que ce soit x86-64 ou I64, que ce soit en natif ou en managé avec .Net 2.0.
Alors pourquoi ce revirement stratégique ?
Cette réunion était visiblement critique pour Microsoft. Le fait de faire venir 4 ou 5 program manager de Redmond alors que VS 2005 est en phase de beta n’est pas innocent. Cela montre (ou veut montrer) que C++ est stratégique pour Microsoft.
En effet tous les éditeurs de logiciel sous Windows utilisaient C++ en majorité. Ceux qui ont une base de code importante et des contraintes de migration sont restés sous VC++6. Surtout que la syntaxe de C++.Net n’a pas incité à migrer sous VS2002/2003 dont le seul apport était l’ouverture à .Net (et une STL un peu mieux faite).
A la différence de Visual Basic que Microsoft a pu tué pour forcer à la migration vers VB.Net (au grand dam des VBistes qui ont demandé sans succès le support du VB “classique” dans VS.Net), d’autre compilateur supporte C++. Si Microsoft avait abandonné le C++ “natif” pour pousser à la migration vers C++.Net, surtout dans sa syntaxe à base de __, le risque aurait été grand de voir ses clients migrer vers d’autre compilateurs (commerciaux ou open-source).
Bref la concurrence a du bon !
mai 14th, 2005 à 3:18
Une bonne analyse. Je me sens quand même obligé de signaler que VB 6-, c’est euh… enfin c’est même pas un outil, ce machin-là quoi… Le runtime est d’une instabilité à faire passer le Titanic des derniers instants pour une valeur sûre, et n’a jamais été corrigé.
Je note quand même l’absence d’allusions aux versions 64-bits de Windows, et à la compatibilité entre les codes sources 32 et 64 (C et C++ n’imposent pas le format de la plupart des types, pour rappel). Est-il prévu, voire recommandé, pour les développeurs, de continuer à développer en 32-bits même pour les machines 64, la couche de compatibilité se chargeant de faire tourner les exécutables, ou une optimisation pour les nouvelles machines est-elle prévue ? (Désolé, moi mon OS est en 64 bits natif et mon compilo c’est GCC, alors je sais vraiment pas, et l’info m’intéresse)
mai 14th, 2005 à 9:36
Exact, j’ai ajouté ce point dans la note.
Je ne conteste pas vraiment ta critique de VB, bien que la version 6 soit bien meilleure que les précédentes en terme de stabilité. Le problème vient surtout du fait qu’il y a beaucoup de développeur VB qui ont du mal à passer à VB.Net (no comment).
Personnellement n’ayant qu’un P4 sur mon PC, je n’ai pas encore de manque quand au 64 bits. Et c’est aussi le cas de beaucoup d’entreprise sous Wintel.
mai 17th, 2005 à 13:02
VB 6 est full 32-bits, là où VB 5- est au mieux 16/32, avec un historique DOS à faire fuir les plus braves de nos collègues… VB 7+ est un vrai langage orienté objet, et non plus "basé sur des objets", tel que le fut son prédécesseur. Je pense qu’à part le côté pratique de la concaténation de chaînes dans VB 6, rien ne peut justifier de garder cette vieille bouse… Et ce côté pratique, instinctif, moi je le trouve plutôt inutile et déplacé pour un programmeur objet. VB 6, c’est un environnement/langage d’amateurs. Il est dommage pour les amateurs qu’il ne soit plus maintenu, mais le fait que des bureaucrates débiles en aient imposé l’utilisation à des professionnels de l’informatique était devenu intolérable. Je remercie Microsoft (pour une fois !) d’avoir enfin réparé les choses, même si ce fut un peu brutalement.
mai 17th, 2005 à 16:33
Mais du coup Microsoft ce retrouve face à ce qui empêche beaucoup de ses clients de passer à Mac ou Linux : le coût de basculement (cost of switching). En effet les milliers/millions de ligne de code en VB ne seront pas facilement migrés en VB.Net. Donc VB6 sera encore utilisé longtemps.