Fichiers de bibliothèque standard C (CRT) et C++ (STL) .lib

Cet article répertorie les fichiers de bibliothèque .lib de runtime Microsoft C auxquels vous pouvez établir un lien lorsque vous développez votre application, ainsi que leurs options de compilateur et directives de préprocesseur associées.

Consultez Redistribuer des fichiers Visual C++ si vous recherchez des informations sur le déploiement des fichiers runtime C nécessaires pour prendre en charge votre application.

Consultez la référence de la bibliothèque runtime C si vous recherchez des informations de référence sur l’API pour la bibliothèque runtime C.

Du point de vue historique, « STL » a initialement fait référence à la bibliothèque de modèles standard écrite par Alexander Stepanov. Certaines parties de cette bibliothèque ont été normalisées dans la bibliothèque standard C++. La bibliothèque standard intègre également la bibliothèque runtime ISO C, les parties de la bibliothèque Boost et d’autres fonctionnalités. Parfois, « STL » est utilisé pour faire référence aux conteneurs et aux algorithmes de la bibliothèque standard C++ adaptée à partir du STL de Stepanov. Dans cette documentation, la bibliothèque de modèles standard (STL) fait référence à la bibliothèque standard C++ dans son ensemble.

Fichiers runtime .lib C

La bibliothèque standard ISO C fait partie de la bibliothèque standard C++. Les bibliothèques Visual C++ qui implémentent le CRT prennent en charge le développement du code natif ainsi que le code natif et managé mixte. Toutes les versions du CRT prennent en charge le développement multithread. La plupart des bibliothèques prennent en charge la liaison statique, pour lier la bibliothèque directement à votre code, ou la liaison dynamique pour permettre à votre code d’utiliser les fichiers DLL communs.

Dans Visual Studio 2015, le CRT a été refactorisé en nouveaux fichiers binaires. La bibliothèque Universal CRT (UCRT) contient les fonctions et variables globales exportées par la bibliothèque CRT C99 standard. L’UCRT est désormais un composant Windows et est fourni dans le cadre de Windows 10 et versions ultérieures. La bibliothèque statique, la bibliothèque d’importation DLL et les fichiers d’en-tête pour l’UCRT se trouvent désormais dans le Kit de développement logiciel (SDK) Windows. Lorsque vous installez Visual C++, le programme d’installation de Visual Studio installe le sous-ensemble du Kit de développement logiciel (SDK) Windows requis pour utiliser l’UCRT. Vous pouvez utiliser l’UCRT sur n’importe quelle version de Windows prise en charge par Visual Studio 2015 et ultérieur. Vous pouvez la redistribuer à l’aide de vcredist pour les versions prises en charge de Windows autres que Windows 10 ou version ultérieure. Pour plus d’informations, consultez Redistribution des fichiers Visual C++.

Le tableau suivant répertorie les bibliothèques qui implémentent l’UCRT.

La bibliothèque vcruntime contient du code spécifique à l’implémentation CRT Visual C++ : prise en charge de la gestion et du débogage des exceptions, case activée s d’exécution et informations de type, détails de l’implémentation et certaines fonctions de bibliothèque étendues. La version de la bibliothèque vcruntime doit correspondre à la version du compilateur que vous utilisez.

Ce tableau répertorie les bibliothèques qui implémentent la bibliothèque vcruntime.

Le code qui initialise le CRT se trouve dans l’une des nombreuses bibliothèques, selon que la bibliothèque CRT est liée de manière statique ou dynamique, ou que le code est natif, managé ou mixte. Ce code gère le démarrage du CRT, l’initialisation interne des données par thread, et l’arrêt. Elle est spécifique à la version du compilateur utilisée. Cette bibliothèque est toujours liée de manière statique, même quand vous utilisez un UCRT lié de manière dynamique.

Ce tableau répertorie les bibliothèques qui implémentent l’initialisation et l’arrêt du CRT.

Si vous liez votre programme à partir de la ligne de commande sans option de compilateur qui spécifie une bibliothèque runtime C, l’éditeur de liens utilisera les bibliothèques CRT liées statiquement : libcmt.lib, libvcruntime.libet libucrt.lib.

L'utilisation du CRT lié de manière statique implique que les informations d'état enregistrées par la bibliothèque runtime C sont locales pour cette instance du CRT. Par exemple, si vous utilisez strtok un CRT lié statiquement, la position de l’analyseur strtok n’est pas liée à l’état utilisé dans le strtok code dans le même processus (mais dans une DLL ou EXE différente) liée à une autre instance du CRT statique. En revanche, le CRT lié dynamiquement partage l'état pour tout le code dans un processus qui est lié dynamiquement au CRT. Cette préoccupation ne s’applique pas si vous utilisez les nouvelles versions plus sécurisées de ces fonctions ; par exemple, strtok_s n’a pas ce problème.

Étant donné qu’une DLL créée en liant à un CRT statique a son propre état CRT, nous vous déconseillons de lier statiquement au CRT dans une DLL, sauf si les conséquences sont comprises et souhaitées. Par exemple, si vous appelez _set_se_translator un exécutable qui charge la DLL liée à son propre CRT statique, toutes les exceptions matérielles générées par le code dans la DLL ne seront pas interceptées par le traducteur, mais les exceptions matérielles générées par le code dans l’exécutable principal seront interceptées.

Si vous utilisez le commutateur du /clr compilateur, votre code est lié à une bibliothèque statique. msvcmrt.lib La bibliothèque statique fournit un proxy entre votre code géré et la bibliothèque CRT native. Vous ne pouvez pas utiliser le CRT lié statiquement ( /MT ou /MTd les options) avec /clr. Utilisez les bibliothèques liées dynamiquement (/MD ou /MDd) à la place. Les bibliothèques CRT managées pures sont déconseillées dans Visual Studio 2015 et non prises en charge dans Visual Studio 2017.

Pour plus d’informations sur l’utilisation du CRT avec /clr, consultez Assemblys mixtes (natifs et managés).

Pour générer une version de débogage de votre application, l’indicateur _DEBUG doit être défini et l’application doit être liée à une version de débogage de l’une de ces bibliothèques. Pour plus d’informations sur l’utilisation des versions de débogage des fichiers de bibliothèque, consultez les techniques de débogage CRT.

Cette version du CRT n’est pas entièrement conforme à la norme C99. Dans les versions antérieures à Visual Studio 2019 version 16.8, l’en-tête <tgmath.h> n’est pas pris en charge. Dans toutes les versions, les CX_LIMITED_RANGE macros pragma et FP_CONTRACT pragma ne sont pas prises en charge. Certains éléments tels que la signification des spécificateurs de paramètres dans les fonctions d’E/S standard utilisent des interprétations héritées par défaut. Vous pouvez utiliser les /Zc options de conformité du compilateur et spécifier des options d’éditeur de liens pour contrôler certains aspects de la conformité de la bibliothèque.

Fichiers de bibliothèque standard C++ (STL) .lib

Lorsque vous générez une version de version de votre projet, l’une des bibliothèques de runtime C de base (libcmt.lib, , msvcmrt.libmsvcrt.lib) est liée par défaut, selon l’option du compilateur que vous choisissez (multithreaded, DLL, /clr). Si vous incluez l’un des fichiers d’en-tête de la bibliothèque standard C++ dans votre code, une bibliothèque standard C++ est liée automatiquement par Visual C++ au moment de la compilation. Par exemple :

#include <ios>

Pour la compatibilité binaire, plusieurs fichiers DLL peuvent être spécifiés par une seule bibliothèque d’importation. Les mises à jour de version peuvent introduire des bibliothèques dot, des DLL séparées qui introduisent de nouvelles fonctionnalités de bibliothèque. Par exemple, Visual Studio 2017 version 15.6 a introduit pour prendre en msvcp140_1.dll charge davantage de fonctionnalités de bibliothèque standard sans rompre l’interface binaire d’application (ABI) prise en charge par msvcp140.dll. La msvcprt.lib bibliothèque d’importation incluse dans l’ensemble d’outils pour Visual Studio 2017 version 15.6 prend en charge les dll et le vcredist pour cette version installe les deux DLL. Une fois livrée, une bibliothèque dot a une ABI fixe et n’aura jamais de dépendance avec une bibliothèque dot ultérieure.

Quels sont les problèmes qui peuvent se poser si une application utilise plusieurs versions du CRT ?

Chaque image exécutable (EXE ou DLL) peut avoir son propre CRT lié statiquement, ou peut être liée de manière dynamique à un CRT. La version du CRT statique incluse ou chargée dynamiquement par une image particulière dépend de la version des outils et des bibliothèques avec lesquels elle a été créée. Un même processus peut charger plusieurs images EXE et DLL, chacune avec son propre CRT. Chacun de ces CRT peut utiliser un allocateur différent, avoir des dispositions de structure interne différentes, et utiliser des dispositions de stockage différentes. Cela signifie que la mémoire allouée, les ressources CRT ou les classes passées à travers une limite DLL peuvent entraîner des problèmes de gestion de la mémoire, d’utilisation statique interne ou d’interprétation de disposition. Par exemple, si une classe est allouée dans une DLL, mais passée puis supprimée par une autre, quel est l’annulateur d’allocation CRT utilisé ? Les erreurs provoquées peuvent aller du subtil au immédiatement irrécupérable, et par conséquent le transfert direct de ces ressources est déconseillé.

Vous pouvez éviter un grand nombre de ces problèmes à l’aide des technologies ABI (Application Binary Interface) à la place, car elles sont conçues pour être stables et versionsables. Concevez vos interfaces d’exportation DLL pour passer les informations par valeur ou pour utiliser une mémoire passée par l’appelant plutôt qu’allouée localement puis retournée à l’appelant. Utilisez des techniques de marshaling pour copier des données structurées entre des images exécutables. Encapsulez les ressources localement et autorisez uniquement la manipulation au moyen de handles ou de fonctions que vous exposez aux clients.

Il est également possible d’éviter certains de ces problèmes si toutes les images de votre processus utilisent la même version chargée dynamiquement du CRT. Pour vous assurer que tous les composants utilisent la même version DLL du CRT, générez-les à l’aide de l’option /MD et utilisez le même ensemble d’outils de compilateur et les mêmes paramètres de propriété.

Veillez à ce que votre programme passe certaines ressources CRT au-delà des limites de DLL. Les ressources telles que les handles de fichiers, les paramètres régionaux et les variables d’environnement peuvent entraîner des problèmes, même lors de l’utilisation de la même version du CRT. Pour plus d’informations sur les problèmes impliqués et sur la façon de les résoudre, consultez Erreurs potentielles en passant des objets CRT à travers les limites de DLL.

Voir aussi

Informations de référence sur la bibliothèque Runtime C
Redistribution des fichiers Visual C++