Chapitre 2 : Microsoft Visual C++

Les langages de programmation C, C++, C++/CLI et C++/CX sont tous pris en charge par Microsoft Visual C++ (MSVC), qui est un compilateur complet pour ces langages. Microsoft Visual Studio (MSVC) est un logiciel appartenant à Microsoft. Initialement, il s'agissait d'un produit indépendant, mais il a finalement été intégré à Visual Studio et mis à disposition en version d'essai et en version gratuite. Il comprend des outils de développement d'applications et de débogage pour le code C++, en particulier le code écrit pour l'interface de programmation d'applications (API) Windows, DirectX and.NET.

Par conséquent, les packages de bibliothèque d'exécution Visual C++ redistribuables sont nécessaires au bon fonctionnement d'un grand nombre de programmes. Il est courant d'installer ces packages indépendamment des applications qu'ils prennent en charge. Cela permet à de nombreux programmes d'utiliser le paquet avec une seule installation. La majorité de ces packages redistribuables et d'exécution Visual C++ sont configurés pour être installés pour des bibliothèques standard, qui sont utilisées par diverses applications.

Le langage de programmation qui a précédé Visual C++ était connu sous le nom de Microsoft C/C++. De plus, il existait une version 2.5 de Microsoft QuickC ainsi qu'une version 1.0 de Microsoft QuickC pour Windows. Microsoft C/C++ est toujours le nom du compilateur utilisé pour Visual C++, et à partir de la publication de Visual C++ 2015 Update 2, il s'exécute désormais sur la version 14.0.23918.0.

Lorsqu'il s'agit de Visual C ou C++, il existe une variété de numéros de version différents qui doivent être pris en considération. Le numéro de version du compilateur est celui qui n'a cessé d'augmenter depuis les premiers jours du compilateur C de Microsoft. C'est aussi celui qui est le plus ancien et le plus développé à l'origine d'entre eux. Lorsque la commande cl.exe est exécutée seule, sans qu'aucun argument ne soit spécifié, c'est la version qui est renvoyée. De plus, cela devient la valeur de la macro du préprocesseur C connue sous le nom de _MSC_VER, ainsi que la valeur de la variable CMake connue sous le nom de MSVC_VERSION. Pour ce faire, il suffit de prendre deux chiffres après la virgule décimale et de supprimer la virgule. Afin de différencier les différentes versions du compilateur de manière plus granulaire, le _MSC_FULL_VER macro C a été étendu à une version plus longue. Par exemple, la version 19.33 du compilateur Microsoft C/C++ est représentée par la valeur 1933 pour la variable _MSC_VER et la valeur 193331630 pour la variable _MSC_FULL_VER.

La version du produit Visual désigne la version de Visual Studio qui a été utilisée pour empaqueter la version 19.33 du compilateur. Par exemple, « 17.3.4 » spécifie la version de Visual Studio. Il existe également la version de la bibliothèque d'exécution Microsoft Visual C/C++, qui est désignée par le numéro « 14.3 ». Cela permet de déduire la version de l'ensemble d'outils, qui peut être dérivée en supprimant la décimale des trois premiers chiffres de la version de la bibliothèque d'exécution, par exemple « 143 ». Par conséquent, il s'agit d'une autre façon de déterminer la version de l'ensemble d'outils. Les compilateurs, les liens, les assembleurs et autres outils de construction, ainsi que les bibliothèques et les fichiers d'en-tête correspondants, sont tous inclus dans ce package. En outre, il contient la bibliothèque d'exécution Visual C pour C++. Cette table, qui peut être grattée, contient les numéros de version connus qui sont associés les uns aux autres.

Entre les versions majeures du compilateur, l'ABI du compilateur Visual C++ a traditionnellement subi un certain nombre de modifications. C'est notamment le cas des conteneurs STL, dont la taille varie considérablement d'une version à l'autre du compilateur. Pour cette raison, Microsoft déconseille d'utiliser des interfaces C++ aux limites des modules lorsque l'on souhaite activer le code client généré à l'aide d'une version différente du compilateur. L'utilisation d'interfaces C ou COM, qui sont censées avoir une interface de programmation d'application (ABI) cohérente entre les mises à jour du compilateur, est ce que Microsoft recommande d'utiliser plutôt que C++.

Il existe une ABI stable dans chaque version 14.x de MSVC, et les fichiers binaires créés avec ces versions peuvent être mélangés de manière compatible avec les versions ultérieures. Cependant, il est important de noter qu'il existe plusieurs contraintes qui s'appliquent :

Il existe plusieurs versions des bibliothèques d'exécution C incluses dans Visual C++. Cela indique que les utilisateurs sont en mesure de compiler leurs programmes à l'aide de n'importe quelle bibliothèque accessible. Il est toutefois possible que cela entraîne des problèmes lors de l'utilisation de plusieurs composants (DLL et EXE) au sein du même logiciel. Un exemple typique est un programme qui utilise une variété de bibliothèques. Il est recommandé à l'utilisateur d'utiliser le même runtime C pour tous les composants du programme, à moins que les ramifications ne lui soient entièrement communiquées. Pour éviter tout problème potentiel, Microsoft suggère d'utiliser la bibliothèque de liens dynamiques multithread, accessible avec l'option de compilateur /MD ou /MDd.

Malgré le fait que le CRT de Microsoft prend en charge une partie importante des interfaces POSIX, le compilateur Visual C++ émettra, par défaut, un avertissement si de telles fonctions sont utilisées. La raison en est qu'en raison du fait que les normes C et C++ exigent qu'un préfixe de soulignement soit placé avant les interfaces définies par l'implémentation, l'utilisation de ces fonctions n'est pas considérée comme standard. D'un autre côté, les systèmes qui sont véritablement conformes à POSIX n'accepteraient pas ces noms qui sont mis en évidence, et il serait plus portable de simplement désactiver l'avertissement à la place.

Bien que le logiciel ait été initialement conçu comme un environnement de développement intégré (IDE) pour le langage de programmation C, la prise en charge de ce langage par le compilateur n'était compatible qu'avec la première édition de la norme C, publiée en 1989. Il n'a pas respecté la révision C99 de la norme. Avant 2011, plus d'une décennie après la publication de C99, il n'y avait aucun plan en place pour fournir un support pour le logiciel.

Bien qu'il ne soit pas encore terminé, Visual C++ 2013 a finalement implémenté la prise en charge d'un certain nombre de fonctionnalités C99 dans son mode C. Ces fonctionnalités comprenaient des initialiseurs désignés, des littéraux composés et le type _Bool. La prise en charge de C99 a été encore améliorée avec Visual C++ 2015, qui incluait la prise en charge complète de la bibliothèque standard C99. La seule exception à cela était l'inclusion de fonctionnalités qui nécessitaient des fonctionnalités du langage C99 que le compilateur ne prenait pas encore en charge.

Lors de la sortie de Visual C++ 2017, la majorité des modifications apportées à la norme dans la révision C11 n'étaient toujours pas prises en charge. Par exemple, l'incapacité du compilateur à prendre en charge les sélections génériques effectuées par l'utilisation du mot-clé _Generic, ce qui entraînerait des erreurs de grammaire.

En 2018, le préprocesseur a fait l'objet d'une refonte complète, et le C11 se profile à l'horizon :

La mise à jour du préprocesseur n'est que la première étape du processus visant à atteindre une conformité totale avec C11, qui est actuellement dans notre plan. Étant donné que la fonction C11 _Generic n'est pas vraiment un composant du préprocesseur, son implémentation n'a pas encore eu lieu. Lorsqu'il sera enfin mis en action, je prévois que la fonctionnalité fonctionnera indépendamment de l'utilisation de la logique de préprocesseur conventionnelle ou moderne.

_For mois de février de l'année 2020, le support générique s'est engagé auprès de MSVC.

Microsoft a annoncé en septembre 2020 que la prise en charge des normes C11 et C17 serait ultérieurement incluse dans la version 16.8 de MSVC. Microsoft a mentionné qu'ils visaient à ajouter la prise en charge des atomics et des threads à une date ultérieure, mais cela n'incluait aucune fonctionnalité qui pourrait être considérée comme facultative avec le produit. C'est dans la version 17.5 que la prise en charge des atomiques a été ajoutée, et c'était à la fois expérimental et partiel. La prise en charge expérimentale signifie qu'elle est cachée derrière l'indicateur de compilateur /experimental :c11atomics. Dans la version 17.8, la prise en charge des threads a été ajoutée, mais cette fois-ci, elle n'était pas cachée derrière un drapeau de compilateur.

Étant donné que MSVC n'effectue pas de recherche de nom en deux phases lorsqu'il est configuré avec ses paramètres par défaut, il n'est pas en mesure d'identifier une grande variété de code erroné. La majorité des vérifications sont reportées jusqu'à ce que le modèle soit instancié. Cependant, afin de corriger ce comportement, des versions plus récentes doivent être installées et l'option de ligne de commande /permissive- doit être utilisée.

En février 1989, BYTE a pris la décision d'approuver la prise en charge d'OS/2, QuickC pour le développement interactif et le débogueur CodeView qui étaient inclus dans Microsoft C 5.1. Ils l'ont qualifié d'« exceptionnel ». Le magazine a déclaré que les développeurs « peuvent toujours préférer les outils plus...