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

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

Consulte Redistribuir archivos de Visual C++ si busca información sobre cómo implementar los archivos en tiempo de ejecución de C necesarios para la compatibilidad con la aplicación.

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

Desde una perspectiva histórica, "STL" se refería originalmente a la biblioteca de plantillas estándar escrita por Alexander Stepanov. Las partes de esa biblioteca se estandarizaron en la biblioteca estándar de C++. La biblioteca estándar también incorpora la biblioteca en tiempo de ejecución ISO C, partes de la biblioteca Boost y otras funciones. A veces se usa "STL" para hacer referencia a las partes de contenedores y algoritmos de la biblioteca estándar de C++ adaptada del STL de Stepanov. En esta documentación, la biblioteca de plantillas estándar (STL) hace referencia a la biblioteca estándar de C++ en su conjunto.

Archivos .lib de tiempo de ejecución de C

La biblioteca estándar ISO C forma parte de la biblioteca estándar de 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.

En Visual Studio 2015, el CRT se refactorizó en nuevos archivos binarios. CRT Universal (UCRT) contiene las funciones y variables globales exportadas por la biblioteca CRT del estándar C99. El UCRT ahora es un componente de Windows y se incluye en Windows 10 y versiones posteriores. La biblioteca estática, la biblioteca de importación de DLL y los archivos de encabezado para UCRT ahora se encuentran en Windows SDK. Cuando se instala Visual C++, el programa de instalación de Visual Studio instala el subconjunto de Windows SDK necesario para usar UCRT. Se puede usar el UCRT en cualquier versión de Windows compatible con Visual Studio 2015 y versiones posteriores. También se puede redistribuir mediante vcredist para las versiones compatibles de Windows que no sean Windows 10 o posteriores. 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 vcruntime contiene código específico de implementación de CRT de Visual C++: compatibilidad con la depuración y control de excepciones, comprobaciones en tiempo de ejecución e información de tipos, detalles de implementación y determinadas funciones de biblioteca extendidas. 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ífico de la versión del compilador que se use. 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 de compilador que especifique una biblioteca en tiempo de ejecución de C, el enlazador usará las bibliotecas de 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 utiliza strtok cuando se use CRT vinculado estáticamente, la posición del analizador de strtok no tiene relación con el estado de strtok que se usa en el código en el mismo proceso (pero en otro archivo DLL o EXE) vinculado a otra instancia de CRT 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 da si usa las nuevas versiones más seguras de estas funciones. Por ejemplo, strtok_s no presenta este problema.

Dado que un archivo DLL compilado mediante la vinculación a un CRT estático tiene su propio estado de CRT, no se recomienda vincular estáticamente al CRT en un archivo DLL a menos que se comprendan y deseen las consecuencias. Por ejemplo, si llama a _set_se_translator en un archivo ejecutable que cargue el DLL vinculado a su propio CRT estático, el traductor no detectará ninguna excepción de hardware que genere el código del archivo DLL, pero se detectarán las excepciones de hardware que genere el código del archivo ejecutable principal.

Si usa el modificador de compilador /clr, el código se vinculará a 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 una instancia de CRT vinculado estáticamente (opciones /MT o /MTd) con /clr. En su lugar, use las bibliotecas vinculadas dinámicamente (/MD o /MDd). 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 cómo usar CRT con /clr, consulte Ensamblados mixtos (nativos y administrados).

Para compilar una versión de depuración de la aplicación, debe estar definida la marca _DEBUG y la aplicación se debe vincular a una versión de depuración de una de estas bibliotecas. Para obtener más información sobre el uso de las versiones de depuración de los archivos de biblioteca, consulte Técnicas de depuración de CRT.

Esta versión de CRT no es totalmente conforme con el estándar C99. En las versiones de Visual Studio 2019 anteriores a 16.8, no se admite el encabezado <tgmath.h>. Las macros CX_LIMITED_RANGE y FP_CONTRACT pragma no se admiten en ninguna versión. 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. Se pueden usar opciones de conformidad del compilador /Zc y se pueden especificar las opciones del enlazador para controlar algunos aspectos de conformidad de la biblioteca.

Archivos de biblioteca estándar (STL) .lib de C++

Cuando compile una versión de lanzamiento del proyecto, una de las bibliotecas en tiempo de ejecución básicas de C (libcmt.lib, msvcmrt.lib, msvcrt.lib) se vincula de forma predeterminada, según la opción de compilador que elija (multiproceso, DLL, /clr). Si incluye uno de los archivos de encabezado de la biblioteca estándar de C++ en el código, Visual C++ vinculará automáticamente una biblioteca estándar de 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, La versión 15.6 de Visual Studio 2017 introdujo msvcp140_1.dll para admitir una funcionalidad de biblioteca más estándar sin interrumpir la interfaz binaria de aplicaciones (ABI) compatible con msvcp140.dll. La biblioteca de importación msvcprt.lib incluida en el conjunto de herramientas para la versión 15.6 de Visual Studio 2017 admite ambos DLL y el elemento vcredist de esta versión los instala ambos. 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. 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 los 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 utilizan la misma versión DLL de CRT, compílelos mediante la opción /MD y use el mismo conjunto de herramientas y configuración de propiedades del compilador.

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

Consulte también

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