Archivos de tiempo de ejecución de C (CRT) y biblioteca estándar de C++ (STL) .lib

En este tema se enumeran los archivos de biblioteca en tiempo de ejecución de Microsoft C con los que puede vincular al desarrollar la aplicación, así como sus opciones de compilador asociadas y directivas .lib de preprocesador.

Consulte Redistribuir Visual C++ si busca información sobre la implementación de los archivos en tiempo de ejecución de C necesarios para admitir la aplicación.

Consulte Referencia de la biblioteca en tiempo de ejecución de C si busca la referencia de API para la biblioteca en tiempo de ejecución de C.

Archivos en tiempo de ejecución de C .lib

La biblioteca en tiempo de ejecución de C (CRT) es la parte de la biblioteca estándar de C++ que incorpora la biblioteca estándar ISO C. Las bibliotecas de Visual C++ que implementan CRT admiten el desarrollo de código nativo, así como código mixto (nativo y administrado) y código administrado. Todas las versiones de CRT admiten el desarrollo multiproceso. La mayoría de las bibliotecas admite la vinculación estática, para vincular la biblioteca directamente en el código, o la vinculación dinámica para permitir que el código use archivos DLL comunes.

A partir de Visual Studio 2015, el CRT se ha refactorizado en nuevos binarios. CRT Universal (UCRT) contiene las funciones y variables globales exportadas por la biblioteca CRT del estándar C99. El UCRT es ahora un componente Windows y se distribuye como parte de Windows 10 y versiones posteriores. La biblioteca estática, la biblioteca de importación de DLL y los archivos de encabezado del UCRT ahora se encuentran en el SDK Windows. Al instalar Visual C++, Visual Studio instalación instala el subconjunto del SDK de Windows necesario para usar el UCRT. Se puede usar el UCRT en cualquier versión de Windows compatible con Visual Studio 2015 y versiones posteriores. Puede redistribuirlo mediante vcredist para las versiones admitidas de Windows que no Windows 10 o posterior. Para obtener más información, consulte Redistribuir archivos de Visual C++.

En la tabla siguiente se muestran las bibliotecas que implementan el UCRT.

La biblioteca de vcruntime contiene código específico de la implementación de CRT en Visual C++ como, por ejemplo, compatibilidad con la depuración y el control de excepciones, comprobaciones en tiempo de ejecución e información de tipos, detalles de la implementación y determinadas funciones de biblioteca ampliada. La versión de la biblioteca vcruntime debe coincidir con la versión del compilador que está usando.

En la siguiente tabla se muestran las bibliotecas que implementan la biblioteca vcruntime.

El código que inicializa el CRT está en una de varias bibliotecas, en función de si la biblioteca CRT está vinculada estática o dinámicamente o es código nativo, administrado o mixto. Este código controla el inicio de CRT, la inicialización de datos internos por subproceso y la terminación. Es específica de la versión del compilador utilizada. Esta biblioteca siempre se vincula estáticamente, incluso cuando se usa un UCRT vinculado dinámicamente.

En la siguiente tabla se muestran las bibliotecas que implementan la inicialización y la terminación de CRT.

Si vincula el programa desde la línea de comandos sin una opción del compilador que especifique una biblioteca en tiempo de ejecución de C, el enlazador usará las bibliotecas crt vinculadas estáticamente: libcmt.lib , libvcruntime.lib y libucrt.lib .

El uso de CRT vinculado estáticamente implica que toda información de estado que guarde la biblioteca en tiempo de ejecución de C será local en esa instancia de CRT. Por ejemplo, si usa al usar crt vinculado estáticamente, la posición del analizador no está relacionada con el estado usado en el código en el mismo proceso (pero en un archivo DLL o EXE diferente) que está vinculado a otra instancia de strtokstrtok CRT strtok estático. Por el contrario, CRT vinculado dinámicamente tiene el mismo estado para todo el código de un proceso que se vincule dinámicamente a CRT. Este problema no se aplica si usa las nuevas versiones más seguras de estas funciones. por ejemplo, strtok_s no tiene este problema.

Dado que un archivo DLL creado mediante la vinculación a un CRT estático tiene su propio estado de CRT, no se recomienda vincular estáticamente a CRT en un archivo DLL a menos que las consecuencias de esto se den y entiendan específicamente. Por ejemplo, si llama a en un archivo ejecutable que carga el archivo DLL vinculado a su propio CRT estático, el traductor no capturará las excepciones de hardware generadas por el código en el archivo DLL, pero se capturarán las excepciones de hardware generadas por el código en el ejecutable _set_se_translator principal.

Si usa el modificador del compilador, el código /clr se vinculará con una biblioteca estática, msvcmrt.lib. La biblioteca estática proporciona un proxy entre el código administrado y CRT nativo. No se puede usar crt vinculado estáticamente ( /MT o /MTd opciones) con /clr . En su lugar, use las bibliotecas vinculadas dinámicamente ( /MD/MDd o ). Las bibliotecas de CRT administradas puras están en desuso en Visual Studio 2015 y no se admiten en Visual Studio 2017.

Para obtener más información sobre el uso de CRT con /clr , vea /clr

Para compilar una versión de depuración de la aplicación, se debe definir la marca y la aplicación debe vincularse con una versión _DEBUG de depuración de una de estas bibliotecas. Para obtener más información sobre cómo usar las versiones de depuración de los archivos de biblioteca, vea Técnicas de depuración de CRT.

Esta versión de CRT no es totalmente compatible con el estándar C99. En las versiones anteriores Visual Studio versión 16.8 de 2019, no se admite el encabezado < tgmath.h. > En todas las versiones, no CX_LIMITED_RANGE se FP_CONTRACT admiten las macros pragma y . Determinados elementos como el significado de los especificadores de parámetros en las funciones estándar de E/S usan interpretaciones heredadas de forma predeterminada. Puede usar las opciones /Zc de conformidad del compilador y especificar opciones del vinculador para controlar algunos aspectos de la conformidad de la biblioteca.

Archivos de la biblioteca estándar de C++ .lib

Al compilar una versión de lanzamiento del proyecto, una de las bibliotecas básicas en tiempo de ejecución de C ( , , ) está vinculada de forma predeterminada, en función de la opción del compilador que elija libcmt.libmsvcmrt.libmsvcrt.lib (multiproceso, DLL, /clr ). Si incluye uno de los archivos de encabezado de la biblioteca estándar de C++ en el código, se vinculará automáticamente una biblioteca estándar de C++ Visual C++ en tiempo de compilación. Por ejemplo:

#include <ios>

Para la compatibilidad binaria, es posible que sea necesario especificar más de un archivo .dll mediante una única biblioteca de importación. Asimismo, las actualizaciones de versión pueden introducir bibliotecas DOT, es decir, .dll independientes con nuevas funcionalidades de biblioteca. Por ejemplo, Visual Studio versión 15.6 de 2017 se introdujo para admitir funcionalidades de biblioteca estándar adicionales sin romper la interfaz binaria de aplicación msvcp140_1.dll (ABI) compatible con msvcp140.dll . La biblioteca de importación incluida en el conjunto de herramientas para msvcprt.lib Visual Studio 2017 versión 15.6 admite ambos archivos DLL, y vcredist para esta versión instala ambos archivos DLL. Una vez enviada, una biblioteca DOT tendrá un ABI fijo, y nunca presentará ninguna dependencia con una biblioteca DOT posterior.

¿Qué problemas existen si una aplicación usa más de una versión de CRT?

Cada imagen ejecutable (EXE o DLL) puede tener su propio CRT vinculado estáticamente, o puede vincularse dinámicamente a CRT. La versión de CRT incluida estáticamente o cargada dinámicamente mediante una imagen determinada depende de la versión de las herramientas y bibliotecas con que se haya compilado. Un solo proceso puede cargar varias imágenes EXE y DLL, cada una con su propio CRT. Cada uno de los CRT puede usar un asignador diferente, puede tener diferentes diseños estructura interna y puede usar diferentes disposiciones de almacenamiento. Esto significa que la memoria asignada, los recursos de CRT o las clases que se pasan a través de un límite de DLL pueden causar problemas en la administración de memoria, el uso estático interno o la interpretación del diseño. Por ejemplo, si se asigna una clase en un archivo DLL, pero se pasa y se elimina por otro, ¿qué desasignador de CRT se usa? Los errores causados pueden oscilar entre algo sutil o inmediatamente crítico; por eso, se desaconseja la transferencia directa de estos recursos.

Puede evitar muchos de estos problemas empleando las tecnologías de la interfaz binaria de aplicaciones, ya que están diseñadas para ser estables y versionables. Diseñe las interfaces de exportación de DLL para pasar información por valor, o para trabajar en la memoria que se pasa por el autor de llamada en lugar de la asignada localmente que se devuelve al autor de llamada. Use técnicas de serialización para copiar datos estructurados entre imágenes ejecutables. Encapsule recursos localmente y permita solo la manipulación a través de identificadores o funciones que exponga a los clientes.

También es posible evitar algunos de estos problemas si todas las imágenes del proceso usan la misma versión cargada dinámicamente de CRT. Para asegurarse de que todos los componentes usan la misma versión dll de CRT, compile con la opción y use el mismo conjunto de herramientas del compilador y la misma configuración /MD de propiedades.

Tenga cuidado si el programa pasa determinados recursos de CRT a través de los límites de DLL. Los recursos como identificadores de archivos, configuraciones regionales y variables de entorno pueden causar problemas, incluso cuando se usa la misma versión de CRT. Para obtener más información sobre los posibles problemas y cómo resolverlos, consulte Errores potenciales que pasan los objetos de CRT entre los límites de DLL.

Vea también

Referencia de la biblioteca en tiempo de ejecución de C
Redistribuir archivos de Visual C++