Passer au contenu principal
Cette rubrique décrit les différents commutateurs du compilateur et de l’éditeur de liens Visual C++ que nous recommandons pour le développement avec le Microsoft Game Development Kit (GDK) sur XBOX.
Pour clang/LLVM pour Windows, les mêmes commutateurs sont pris en charge par le biais du frontal clang-cl « de type MSVC ». Quelques commutateurs propres à l’ensemble d’outils clang sont indiqués ci-dessous.

​
Norme du langage C++ (/std)

Visual C++ utilise par défaut le mode de conformité C++14. Pour activer le mode de conformité C++17, utilisez /std:c++17. Les API du Microsoft Game Development Kit (GDK) sur XBOX nécessitent C++11 ou une version ultérieure, et l’utilisation de C++14 ou d’une version ultérieure est entièrement prise en charge pour le développement de titres.
/std:c++latest active la conformité au brouillon C++20 pour Visual Studio 2017 et Visual Studio 2019. Comme le comportement de /std:c++latest continue d’évoluer avec les mises à jour de maintenance de Visual C++, il doit être utilisé avec prudence.
VS 2019 (16.11) et VS 2022 prennent en charge le commutateur /std:c++20. Consultez ce billet de blog.
À partir de VS 2019 (16.8), le compilateur Visual C++ prend en charge /std:c11 et /std::c17. Toutefois, GameRuntime et de nombreux autres en-têtes du GDK nécessitent C++11 ou une version ultérieure.
Pour plus de renseignements, consultez les ressources suivantes :

​
Utilisez /O1 /Oi pour l’optimisation générale et /O2 pour les modules « critiques »

Pour le processeur à exécution dans le désordre des XBOX One et XBOX Series X/S, faire tenir un segment de code dans le cache d’instructions est généralement plus important que d’obtenir la version la plus rapide possible du code; l’option optimiser pour l’espace est donc préférable. Réservez l’option optimiser pour la vitesse à des modules ou fonctions spécifiques. La génération d’intrinsèques vaut le code supplémentaire pour les jeux, car elle améliore les performances en virgule flottante. Vous pouvez aussi activer optimiser pour la vitesse sur une fonction ou un ensemble de fonctions spécifiques en les entourant de #pragma optimize("t", on) / #pragma optimize("", on ). N’oubliez pas que l’option optimiser pour la vitesse (/O2 ou /Ox) peut entraîner une augmentation considérable de la taille du programme en raison du déroulement agressif des boucles.
Les optimisations de l’auto-vectoriseur SIMD (Single Instruction Multiple Data) ne sont activées qu’avec /O2 ou /Ox. L’optimisation guidée par profil (PGO) permet de mieux choisir où appliquer précisément optimiser pour la vitesse plutôt que optimiser pour l’espace.Pour des raisons historiques, il est important de noter que /Ox est presque identique à O2, mais qu’il lui manque /GF (élimination des chaînes en double) et /Gy (activation de l’édition de liens au niveau des fonctions). Vous devez donc en général préférer /O2 à /Ox. Si vous utilisez /Ox, veillez à activer explicitement au moins /Gy, qui est important pour permettre l’optimisation par l’éditeur de liens.

​
Commutateur de compilateur /fp:fast

L’indicateur /fp, introduit avec Visual Studio 2005, contrôle les différents modèles de virgule flottante utilisés par le compilateur (fast, precise, strict, except). Le modèle de virgule flottante rapide utilise un certain nombre d’optimisations qui ne font pas partie des règles « C » de base. Le modèle de virgule flottante précis désactive ces optimisations supplémentaires et constitue le modèle par défaut. Nous recommandons d’utiliser /fp:fast pour les jeux. Pour plus de renseignements, consultez les ressources suivantes : Consultez aussi ces nouveaux indicateurs liés à la virgule flottante dans VS 2022 :

​
Commutateur de compilateur /arch

La valeur par défaut implicite pour les plateformes natives x64 est /arch:SSE2. Pour les consoles XBOX One (processeur AMD Jaguar), utilisez /arch:AVX. Pour les XBOX Series X/S (processeur AMD Hercules), nous recommandons d’utiliser /arch:AVX2. Le principal avantage de /arch:AVX ou /arch:AVX2 est que le compilateur génère des versions à préfixe VEX des instructions SSE, qui utilisent un encodage non destructif à 3 opérandes au lieu de l’encodage standard à 2 opérandes dans lequel l’un des opérandes sources est remplacé par le résultat. Cela concerne à la fois la virgule flottante scalaire du code natif x64 utilisant des instructions SSE et l’utilisation explicite d’intrinsèques SSE. Cela permet de réduire la pression sur la planification des registres et peut éliminer certaines instructions movaps. Pour plus de renseignements, consultez les ressources suivantes : Pour les XBOX Series X|S avec Visual Studio 2019 (16.3) ou version ultérieure, utilisez aussi /d2vzeroupper pour optimiser le code selon le comportement préféré du processeur AMD Hercules en matière d’utilisation de l’instruction vzeroupper. Pour l’optimisation de l’ensemble du programme (/LTCG), l’équivalent requis pour l’éditeur de liens est /d2:-vzeroupper. Il s’agit du comportement par défaut du compilateur de VS 2022. Pour la XBOX One avec Visual Studio 2022, utilisez aussi /d2vzeroupper- pour optimiser le code selon le comportement préféré du processeur AMD Jaguar en matière d’utilisation de l’instruction vzeroupper. Pour l’optimisation de l’ensemble du programme (/LTCG), l’équivalent requis pour l’éditeur de liens est /d2:-vzeroupper-. Il s’agit du comportement par défaut du compilateur de VS 2019.
Pour clang/LLVM, utilisez -march=btver2 pour la XBOX One (processeur AMD Jaguar) et -march=znver2 pour les XBOX Series X/S (processeur AMD Hercules).
Pour le développement sur PC, vous pouvez compter sur la prise en charge de SSE et SSE2 par tous les processeurs natifs x64, car elle fait partie de la définition de l’architecture. Vous pouvez aussi exiger SSE3 sans risque, car il est pris en charge par tous les processeurs Intel modernes compatibles avec Windows 10 ou Windows 11. Veillez à vérifier à l’exécution la prise en charge par le processeur de tout ce que vous utilisez au-delà de SSE2 sur PC, comme AVX ou AVX2.

​
Commutateur de compilateur /favor

Le commutateur /favor contrôle les choix d’optimisation du compilateur x64 pour les processeurs AMD64 par rapport aux processeurs Intel 64. Pour le développement XBOX, utilisez /favor:AMD64.

​
Modèle de gestion des exceptions (/EHsc)

Pour le code natif x64, la gestion des exceptions n’a aucun effet direct sur le code de l’épilogue ou du prologue des fonctions. Alors que Windows x86 utilisait un mécanisme basé sur la pile qui impliquait l’injection de code supplémentaire dans les modules, la génération de code natif x64 utilise un mécanisme basé sur des tables pour garantir que la pile peut être correctement déroulée pendant le traitement des exceptions. Ce mécanisme basé sur des tables a aussi l’avantage d’être plus sûr, car il n’est pas vulnérable aux attaques par dépassement de mémoire tampon de la pile. Cette conception a plusieurs implications.
  • La gestion des exceptions n’affecte pas le nombre d’instructions du code généré. Alors que les mécanismes basés sur la pile comme celui de Windows x86 peuvent entraîner une pénalité de 5 à 10 % sur le code, la gestion des exceptions native x64 ne génère que des données de table associées à l’exécutable, et non des instructions supplémentaires. Même la désactivation explicite de la gestion des exceptions en natif x64, que nous ne recommandons pas, n’économise qu’une petite quantité de données auxiliaires pour la gestion C++ et ne désactive pas la génération des données de déroulement de la pile.
  • Les blocs try/catch sont peu coûteux à utiliser. Un bloc try/catch dans le mécanisme basé sur la pile ajoute du code de suivi supplémentaire. Sur x64, il n’ajoute que quelques entrées dans la table de déroulement.
  • Le traitement des exceptions (c’est-à-dire la levée effective d’une exception) nécessite des recherches supplémentaires dans les tables. Le compromis est le suivant : les mécanismes basés sur la pile peuvent lever des exceptions plus rapidement, mais au prix d’une pénalité sur tous les chemins de code. Le mécanisme basé sur des tables est plus lent pour la « levée », mais n’affecte pas les autres chemins de code. Comme les exceptions ne doivent pas servir au contrôle de flux normal et ne doivent en fait être déclenchées que dans des circonstances exceptionnelles, ce coût de traitement supplémentaire est négligeable par rapport aux performances globales de l’application.
Les API du Microsoft Game Development Kit (GDK) sur XBOX utilisent des codes d’erreur ou des HRESULT plutôt que la gestion des exceptions pour retourner les erreurs; le niveau d’adoption de la gestion des exceptions C++ dans la base de code d’un titre dépend donc entièrement de vous. Les exceptions ne doivent pas servir au contrôle de flux; leur meilleur usage concerne généralement les scénarios « fail-fast », ce qui peut simplifier le débogage et le codage. Une grande partie de la bibliothèque C++ standard suppose que la gestion des exceptions est activée pour une gestion correcte des erreurs. La désactivation explicite de la gestion des exceptions n’est pas recommandée, car elle nuit à l’analyse après incident et n’améliore pas la génération de code. Nous ne recommandons pas l’utilisation de /EHa, car elle peut inhiber l’optimiseur.
L’opérateur new lève toujours une exception C++ en cas d’échec d’allocation. Si vous voulez utiliser une version de new qui ne lève pas d’exception, vous devez utiliser new (std::nothrow). Pour plus de renseignements, consultez std::nothrow (cppreference.com).
C++ fournit de nombreux mécanismes pour écrire du code « sûr vis-à-vis des exceptions » qui fonctionne bien avec ou sans utilisation explicite de la gestion des exceptions, par exemple std::unique_ptr, std::shared_ptr et std::lock_guard. L’utilisation d’un pointeur intelligent COM comme Microsoft::WRL::ComPtr pour gérer automatiquement le comptage de références COM est « sûre vis-à-vis des exceptions » et moins sujette aux erreurs. En général, privilégiez les modèles de codage de type RAII (Resource Acquisition Is Initialization).
Par défaut, le code natif x64 généré avec VS 2019 utilise une implémentation améliorée du gestionnaire d’exceptions ( __CxxFrameHandler4, __GSHandlerCheck_EH4). Les bibliothèques statiques générées avec VS 2019 ne sont donc pas compatibles avec le runtime C/C++ de VS 2017. Les bibliothèques statiques générées avec VS 2017 sont compatibles avec VS 2019.
Pour plus de renseignements, consultez les ressources suivantes :

​
Bibliothèque runtime (/MD, /MDd)

Le choix recommandé consiste à utiliser la version DLL multithread du runtime Visual C/C++. Cela réduit au minimum le gonflement du code, évite les problèmes potentiels d’interaction entre DLL, simplifie la maintenance et constitue l’option recommandée pour toutes les plateformes Microsoft. Pour le Microsoft Game Development Kit (GDK) sur XBOX, cela signifie effectuer l’édition de liens avec ucrt.lib ou ucrtd.lib.
Techniquement, vous pouvez utiliser l’édition de liens statique du CRT par /MT ou /MTd avec libucrt.lib ou libucrtd.lib. Le GDK ne contient pas de bibliothèques d’extension compatibles avec le CRT statique; la prise en charge de ce scénario est donc limitée.

​
Convention d’appel (/Gd, /Gv)

La génération de code natif pour x64 utilise une convention d’appel __fastcall simple et standard, qui peut passer les quatre premiers paramètres dans des registres.
  • Si le premier paramètre est un entier ou un équivalent de pointeur, il est passé dans RCX. S’il s’agit d’un float ou d’un double, il est passé dans XMM0L. Sinon, il est passé par la pile.
  • Si le deuxième paramètre est un entier ou un équivalent de pointeur, il est passé dans RDX. S’il s’agit d’un float ou d’un double, il est passé dans XMM1L. Sinon, il est passé par la pile.
  • Si le troisième paramètre est un entier ou un équivalent de pointeur, il est passé dans R8. S’il s’agit d’un float ou d’un double, il est passé dans XMM2L. Sinon, il est passé par la pile.
  • Si le quatrième paramètre est un entier ou un équivalent de pointeur, il est passé dans R9. S’il s’agit d’un float ou d’un double, il est passé dans XMM3L. Sinon, il est passé par la pile.
  • Tous les autres paramètres sont passés par la pile.
  • Une valeur de retour qui tient sur 64 bits est retournée dans RAX. XMM0 sert à retourner les valeurs float, double, __m128, __m128i et __m128d. Sinon, l’appelant passe un pointeur vers la mémoire en tant qu’argument 0 dans RCX, et RAX doit être retourné avec le même pointeur.
Il en découle que les signatures de fonctions plus courtes sont plus performantes et que le passage de pointeurs (ou de références) vers des objets est plus rapide que le passage par valeur. La convention d’appel passe automatiquement par référence les objets de plus de 8 octets. Les valeurs SIMD ne sont jamais passées dans des registres avec le mécanisme __fastcall.
__cdecl, __stdcall et __thiscall sont tous des alias de __fastcall pour le code natif x64.
Pour plus de renseignements, consultez x64 calling convention (Microsoft Docs).

​
Vector call

Visual Studio prend en charge une convention d’appel facultative appelée __vectorcall pour la génération de code natif x64.
  • Si le premier paramètre est un entier ou un équivalent de pointeur, il est passé dans RCX. S’il s’agit d’un float, d’un double, d’un __m128, d’un __m128i ou d’un __m128d, il est passé dans XMM0. S’il s’agit d’un __m256, d’un __m256i ou d’un __m256d, il est passé dans YMM0. Sinon, le premier paramètre est passé par la pile.
  • Si le deuxième paramètre est un entier ou un équivalent de pointeur, il est passé dans RDX. S’il s’agit d’un float, d’un double, d’un __m128, d’un __m128i, d’un __m128d, d’un __m256, d’un __m256i ou d’un __m256d, il est passé dans XMM1/YMM1. Sinon, le deuxième paramètre est passé par la pile.
  • Si le troisième paramètre est un entier ou un équivalent de pointeur, il est passé dans R8. S’il s’agit d’un float, d’un double, d’un __m128, d’un __m128i, d’un __m128d, d’un __m256, d’un __m256i ou d’un __m256d, il est passé dans XMM2/YMM2. Sinon, le troisième paramètre est passé par la pile.
  • Si le quatrième paramètre est un entier ou un équivalent de pointeur, il est passé dans R9. S’il s’agit d’un float, d’un double, d’un __m128, d’un __m128i, d’un __m128d, d’un __m256, d’un __m256i ou d’un __m256d, il est passé dans XMM3/YMM3. Sinon, le quatrième paramètre est passé par la pile.
  • Si le cinquième paramètre est un float, un double, un __m128, un __m128i, un __m128d, un __m256, un __m256i ou un __m256d, il est passé dans XMM4/YMM4. Sinon, le cinquième paramètre est passé par la pile.
  • Si le sixième paramètre est un float, un double, un __m128, un __m128i, un __m128d, un __m256, un __m256i ou un __m256d, il est passé dans XMM5/YMM5. Sinon, le sixième paramètre est passé par la pile.
  • Tous les autres paramètres sont passés par la pile.
  • Une valeur de retour qui tient sur 64 bits est retournée dans RAX. XMM0 sert à retourner les valeurs float, double, __m128, __m128i et __m128d. YMM0 sert à retourner les valeurs __m256, __m256i ou __m256d. Sinon, l’appelant passe un pointeur vers la mémoire en tant qu’argument 0 dans RCX, et RAX doit être retourné avec le même pointeur.
La convention __vectorcall peut aussi gérer les types d’agrégats vectoriels homogènes (HVA), constitués d’un ou plusieurs membres du même type vectoriel ou à virgule flottante, jusqu’à quatre membres (par exemple, struct * { __m128 v[4]; } est un HVA). En tant que paramètre passé par valeur, un HVA est passé dans des registres si l’espace disponible dans XMM0/YMM0 - XMM5/YMM5 est suffisant après l’allocation des autres paramètres. En tant que valeur de retour, un HVA est retourné par XMM0/YMM0 - XMM3/YMM3.
__vectorcall ne prend pas en charge les fonctions vararg ni les constructeurs C++.
Pour plus de renseignements, consultez les ressources suivantes :

​
Optimisation de l’ensemble du programme (/GL, /Gw, /LTCG)

Alors que les techniques traditionnelles d’optimisation du compilateur peuvent optimiser des fonctions et des modules, l’optimisation de l’ensemble du programme, aussi appelée génération de code au moment de l’édition de liens (LTCG), effectue des optimisations entre les modules. Cela inclut une meilleure allocation et planification des registres grâce à une meilleure connaissance des effets de bord, la propagation interprocédurale des constantes et des plages, l’incorporation partielle et la dévirtualisation des appels de fonctions sur les objets lorsque c’est possible.
La LTCG peut aussi être utilisée en mode incrémentiel pour bénéficier de gains de performances du code lors des itérations de développement. Pour plus de renseignements, consultez Speeding up the Incremental Developer Build Scenario (C++ Team Blog).
Pour les fournisseurs d’intergiciels qui livrent des bibliothèques C++ statiques prégénérées, l’activation de WPO lie la bibliothèque à une version précise de l’ensemble d’outils du compilateur. Dans ce scénario, vous devez livrer des bibliothèques sans WPO. Ce conseil ne s’applique pas aux DLL ni au code généré à partir des sources.
Pour plus de renseignements, consultez /GL (Whole Program Optimization) (Microsoft Docs).
Visual Studio 2022 (17.5) a ajouté un nouveau commutateur de conformité, /Zc:checkGwOdr, lié à /Gw. Consultez ce billet de blog.

​
Optimisation guidée par profil

L’optimisation guidée par profil (PGO) va encore plus loin que le processus LTCG : l’optimisation de l’ensemble du programme est pilotée par des traces de performances recueillies lors d’exécutions antérieures de l’application. Cela améliore la qualité des optimisations existantes ainsi que les optimisations de la disposition des fonctions, de la disposition des blocs et de la séparation du code, pour un meilleur jeu de travail et une meilleure prédiction des branchements. Pour plus de renseignements, consultez Profile-guided optimizations (Microsoft Docs).

​
Commutateur de l’éditeur de liens /OPT:REF,ICF

Ces options éliminent le contenu redondant des différents modules objets lors de l’édition de liens dans l’exécutable final. En général, elles sont désactivées pour les builds de débogage, mais doivent être présentes pour les builds de version.
Pour obtenir les meilleurs résultats, veillez à compiler avec l’option /Gy (activation de l’édition de liens au niveau des fonctions).

​
Commutateur de compilateur /GS

Nous recommandons d’utiliser la vérification des mémoires tampons dans les configurations de version pour tout le code. Dans les cas où certaines mémoires tampons ne présentent aucun risque de sécurité mais où la vérification semble nuire aux performances, utilisez __declspec(safebuffers) sur la fonction plutôt que de désactiver /GS globalement. Pour le code plus risqué, utilisez #pragma strict_gs_check(on). Pour plus de renseignements, consultez /GS (Buffer Security Check) (Microsoft Docs).

​
Commutateur de compilateur /homeparams

L’utilisation de ce commutateur dans les builds optimisés peut grandement améliorer la capacité à déboguer les builds de version de votre application. Utilisé pour les builds de production, il peut simplifier l’analyse et le débogage des vidages sur incident. Il ajoute une légère surcharge due à le stockage de paramètres supplémentaires sur la pile. Dans la plupart des cas, cela n’a pas d’effet notable sur les performances. Pour plus de renseignements, consultez /homeparams (Copy Register Parameters to Stack) (Microsoft Docs).

​
Commutateur de compilateur /Zc:inline

Ce commutateur applique les règles plus strictes de C++11 pour la déclaration des fonctions inline, qui exigent que le corps de toutes les fonctions inline soit présent dans la même unité de compilation que leur déclaration et leur utilisation. L’utilisation de cet indicateur peut améliorer les temps de build et réduire considérablement la taille des fichiers .obj. Si vos fonctions inline ne sont pas conformes à C++11, vous obtiendrez des erreurs LNK2019 lors de l’édition de liens. Ce commutateur est activé par défaut lors des builds avec MSBuild, mais doit être ajouté explicitement lors des builds en ligne de commande, avec CMake, etc. Pour plus de renseignements, consultez /Zc:inline (Remove unreferenced COMDAT) (Microsoft Docs).

​
Commutateur de compilateur /Zc:throwingNew

La norme C++ et les modèles de la bibliothèque C++ standard exigent que l’opérateur new lève une exception plutôt que de retourner nullptr en cas d’échec d’allocation; vous pouvez utiliser std::nothrow avec new pour forcer le renvoi de nullptr. Le compilateur Visual C++ génère depuis longtemps une vérification de null après chaque appel à new, ce qui est inutile en présence de la gestion des exceptions. Ce commutateur élimine ces vérifications supplémentaires. Pour plus de renseignements, consultez les ressources suivantes :

​
Commutateur de compilateur /Zc:__cplusplus

Pour des raisons historiques, la macro __cplusplus de Visual C++ retourne « 199711 » depuis très longtemps. À partir de Visual Studio 2017 (mise à jour 15.7), ce nouveau commutateur amène le compilateur Visual C++ à retourner la valeur standard correcte. Une future version du compilateur le fera par défaut; il est donc judicieux de l’activer le plus tôt possible pour résoudre les éventuels problèmes de conformité persistants. Pour plus de renseignements, consultez les ressources suivantes :

​
Commutateur de compilateur /volatile:iso

Le mot clé volatile présente un certain nombre de comportements étendus propres à Microsoft qui ne sont pas vraiment portables, même entre les générations de Visual C++. Envisagez d’activer ce commutateur, puis de vérifier que vous n’utilisez pas volatile de façon abusive dans votre code. Pour plus de renseignements, consultez /volatile (volatile Keyword Interpretation) (Microsoft Docs).

​
Commutateur de compilateur /permissive-

Visual Studio 2017 a introduit un nouveau commutateur de conformité aux normes pour remplacer le commutateur obsolète /Za. Ce commutateur amène le compilateur à émettre des erreurs et des avertissements lors de l’utilisation de comportements d’extension propres à Microsoft susceptibles de poser des problèmes lors du portage vers d’autres compilateurs. L’utilisation de /permissive- peut aussi améliorer les temps de compilation. Pour plus de renseignements, consultez les ressources suivantes :
À partir de Visual Studio 2017 (mise à jour 15.3), l’utilisation de /permissive- active aussi la recherche de noms en deux phases. Certains codes de modèles C++ ne se compilent pas avec une application correcte de la norme; vous pouvez alors désactiver sélectivement cette seule partie à l’aide de /Zc:twoPhase- au lieu de désactiver entièrement /permissive-.Pour plus de renseignements, consultez les ressources suivantes :
D’autres commutateurs liés à l’application de la conformité incluent /Zc:lambda et /Zc:templateScope.

​
Commutateur de compilateur /Zc:preprocessor

Visual Studio 2019 (16.6) inclut un nouveau commutateur permettant d’activer le préprocesseur conforme à C99. Ce commutateur est désactivé par défaut, mais si la portabilité du code est un enjeu, envisagez de l’activer. Consultez Announcing full support for a C/C++ conformant preprocessor in MSVC.

​
Commutateur de compilateur /ZH:SHA_256

Les symboles de débogage utilisent traditionnellement le hachage MD5. Pour améliorer la sécurité de la chaîne d’approvisionnement, il est recommandé d’utiliser plutôt SHA-256. Notez que Visual Studio 2022 utilise /ZH:SHA_256 par défaut.
Ce commutateur est pris en charge par clang/LLVM à partir de la v16.

​
Commutateurs de l’éditeur de liens /NXCOMPAT et /SAFESEH

Ces deux commutateurs sont implicites lors de l’utilisation de cibles natives x64. La protection de non-exécution (NX) est requise pour les titres XBOX; vous ne pouvez donc pas utiliser /NXCOMPAT:NO.

​
Commutateur de l’éditeur de liens /DYNAMICBASE

Ce commutateur active la randomisation du format de l’espace d’adressage (ASLR) et est activé par défaut. Notez qu’il est requis pour les titres XBOX; vous ne pouvez donc pas utiliser /DYNAMICBASE:NO. Pour Visual Studio 2019 (16.8) ou version ultérieure, les améliorations significatives des performances de l’éditeur de liens font que nous ne recommandons plus d’utiliser /Debug:FASTLINK. Pour les builds locaux, l’activation de ce commutateur de l’éditeur de liens peut grandement améliorer les temps d’itération des builds.
N’oubliez pas qu’avec /Debug:FASTLINK, le pdb principal de votre projet ne contient que des liens vers les fichiers pdb disséminés dans votre build. Si vous voulez partager ou stocker les symboles d’un build /Debug:FASTLINK, vous pouvez utiliser l’outil en ligne de commande mspdbcmf.exe pour générer un fichier pdb complet.Pour plus de renseignements, consultez les ressources suivantes :

​
Bibliothèques

Pour les plateformes Gaming.Xbox.XboxOne.x64 et Gaming.Xbox.Scarlett.x64, il est important d’effectuer l’édition de liens avec xgameplatform.lib. Il s’agit d’une bibliothèque « parapluie » qui inclut toutes les API Win32 prises en charge sur la console. N’effectuez pas l’édition de liens avec kernel32.lib, onecore.lib, onecoreuap.lib ou WindowsApps.lib. Le mélange de bibliothèques parapluies n’est pas recommandé et peut entraîner des échecs au démarrage du processus. Consultez Microsoft Docs pour en savoir plus sur les bibliothèques « parapluies ».

​
Commutateur de l’éditeur de liens /NODEFAULTLIB:library

Nous recommandons d’utiliser le commutateur de l’éditeur de liens /NODEFAULTLIB avec une liste précise de noms de bibliothèques courantes, afin de garantir que des bibliothèques non prises en charge ne sont pas utilisées lors de l’édition de liens par #pragma comment(lib,).
Si une bibliothèque est explicitement répertoriée comme entrée de l’édition de liens, elle est quand même utilisée, même si elle figure dans la liste /NODEFAULTLIB. Le commutateur ignore uniquement les références implicites.

​
Bibliothèques runtime Visual C++

L’invite de commandes développeur de Visual Studio définit les variables d’environnement nécessaires pour localiser ces chemins. Le /LIBPATH approprié pour Gaming.Xbox.*.x64 afin de localiser les bibliothèques d’importation du runtime Visual C++ est %VCToolsInstallDir%lib\onecore\x64.

​
Bibliothèques de liens dynamiques (DLL)

Le Game OS pour Gaming.Xbox.*.x64 n’inclut pas les DLL du runtime Visual C++. Celles-ci doivent être incluses dans la disposition du titre pour que le jeu puisse se lancer.
  • Pour Release, vous avez besoin du contenu de %VCToolsRedistDir%onecore\x64\Microsoft.VC14?.CRT. Si vous avez à la fois des binaires Debug et Release dans la même disposition, incluez-le dans toutes vos dispositions.
  • Pour Debug, vous avez besoin du contenu de %VCToolsRedistDir%onecore\debug_nonredist\x64\Microsoft.VC14?.DebugCRT.
  • Pour Debug, vous avez aussi besoin de la version de débogage de ucrtbased.dll, qui se trouve dans le Windows SDK : %WindowsSdkVerBinPath%x64\ucrt. La version Release de ucrtbase.dll est incluse dans le Game OS.
Si vous utilisez OpenMP, vous avez aussi besoin du contenu de Microsoft.VC14?.OpenMP et/ou Microsoft.VC14?.DebugOpenMP

​
Voir aussi

Exemples CMakeExample
Dernière modification le 8 octobre 2026

Sujets connexes

Utiliser Clang/LLVM avec le GDK pour les consolesUtiliser Clang/LLVM avec le GDKVisual Studio (sommaire)Optimisation guidée par profil dans Visual StudioVisual Studio pour le développement sur console