Arquivos de tempo de execução C (CRT) e biblioteca padrão (STL) .lib C++

Este artigo lista os arquivos de biblioteca .lib de tempo de execução do Microsoft C que você pode vincular ao desenvolver seu aplicativo e suas opções de compilador associadas e diretivas de pré-processador.

Consulte Redistribuindo arquivos do Visual C++, se você estiver procurando informações sobre como implantar os arquivos de runtime C necessários para dar suporte ao aplicativo.

Consulte a referência da biblioteca de runtime C, se você estiver procurando por referência de API para a biblioteca de runtime C.

De uma perspectiva histórica, originalmente, "STL" se referia à Biblioteca de Modelos Padrão escrita por Alexander Stepanov. Partes dessa biblioteca foram padronizadas na biblioteca padrão C++. A biblioteca padrão também incorpora a biblioteca de tempo de execução ISO C, partes da biblioteca Boost e outras funcionalidades. Às vezes, "STL" é usado para se referir aos contêineres e algoritmos, partes da biblioteca padrão C++ adaptada da STL de Stepanov. Nesta documentação, a STL (Standard Template Library) refere-se à biblioteca padrão C++ como um todo.

Arquivos .lib de runtime C

A biblioteca padrão ISO C faz parte da biblioteca padrão C++. As bibliotecas do Visual C++ que implementam CRT são compatíveis com o desenvolvimento de código nativo e com a combinação de código nativo e gerenciado. Todas as versões do CRT dão suporte ao desenvolvimento multi-threaded. A maioria das bibliotecas dá suporte tanto à vinculação estática, para vincular a biblioteca diretamente no código, quanto à vinculação dinâmica, para permitir que o código use arquivos DLL comuns.

No Visual Studio 2015, a CRT foi refatorada em novos binários. O UCRT (CRT Universal) contém as funções e os globais exportados pela biblioteca CRT C99 padrão. O UCRT agora é um componente do Windows e é fornecido como parte do Windows 10 e versões posteriores. A biblioteca estática, a biblioteca de importação de DLL e os arquivos de cabeçalho para o UCRT agora são encontrados no SDK do Windows. Ao instalar o Visual C++, a instalação do Visual Studio instalará o subconjunto do SDK do Windows necessário para usar o UCRT. É possível usar o UCRT em qualquer versão do Windows com suporte no Visual Studio 2015 e versões posteriores. Você poderá redistribuí-lo usando o vcredist para versões do Windows com suporte diferentes do Windows 10 ou posterior. Para obter mais informações, consulte Redistribuindo arquivos do Visual C++.

A tabela a seguir lista as bibliotecas que implementam o UCRT.

A biblioteca vcruntime contém código específico de implementação CRT do Visual C++: manipulação de exceções e suporte à depuração, verificações de tempo de execução e informações de tipo, detalhes de implementação e determinadas funções de biblioteca estendida. É necessário que versão de biblioteca vcruntime corresponda à versão do compilador que você está usando.

Esta tabela lista as bibliotecas que implementam a biblioteca vcruntime.

O código que inicializa o CRT está em uma das várias bibliotecas, com base no fato de a biblioteca CRT ser vinculada estática ou dinamicamente ou de o código ser nativo, gerenciado ou misto. Esse código manipula a inicialização, a inicialização interna de dados por thread e o encerramento do CRT. É específico para a versão do compilador utilizado. Essa biblioteca é sempre vinculada estaticamente, mesmo ao usar um UCRT vinculado dinamicamente.

Esta tabela lista as bibliotecas que implementam a inicialização e o encerramento do CRT.

Se você vincular o programa pela linha de comando sem uma opção do compilador que especifique uma biblioteca de runtime C, o vinculador usará as bibliotecas de CRT vinculadas estaticamente: libcmt.lib, libvcruntime.lib e libucrt.lib.

O uso do CRT vinculado estaticamente indica que todas as informações de estado salvas pela biblioteca de runtime C serão locais para essa instância do CRT. Por exemplo, se você usar strtok ao utilizar um CRT vinculado estaticamente, a posição do analisador strtok não estará relacionada ao estado strtok utilizado no código no mesmo processo (mas em uma DLL ou EXE diferente) que está vinculado a outra instância do CRT estático. Por outro lado, o CRT vinculado dinamicamente compartilha o estado de todo o código em um processo que está vinculado dinamicamente ao CRT. Essa preocupação não se aplicará se você usar as novas versões mais seguras dessas funções, por exemplo, strtok_s não terá esse problema.

Como uma DLL criada vinculando-se a uma CRT estática tem seu próprio estado CRT, não recomendamos que você vincule estaticamente à CRT em uma DLL, a menos que as consequências sejam compreendidas e desejadas. Por exemplo, se você chamar _set_se_translator em um executável que carrega a DLL vinculada ao seu próprio CRT estático, as exceções de hardware geradas pelo código na DLL não serão capturadas pelo tradutor, mas serão capturadas as exceções de hardware geradas pelo código no executável principal.

Se você estiver usando a opção do compilador /clr, o código será vinculado a uma biblioteca estática, msvcmrt.lib. A biblioteca estática fornece um proxy entre o código gerenciado e o CRT nativo. Não é possível usar o CRT vinculado estaticamente (opções /MT ou /MTd) com /clr. Use as bibliotecas de vínculo dinâmico (/MD ou /MDd). As bibliotecas de CRT gerenciado puro são preteridas no Visual Studio 2015 e sem suporte no Visual Studio 2017.

Para obter mais informações sobre como usar o CRT com /clr, consulte Assemblies mistos (nativos e gerenciados).

Para compilar uma versão de depuração do aplicativo, o sinalizador _DEBUG deverá ser definido e o aplicativo vinculado a uma versão de depuração de uma dessas bibliotecas. Para obter mais informações sobre como usar as versões de depuração dos arquivos de biblioteca, consulte Técnicas de depuração CRT.

Essa versão do CRT não é totalmente compatível com o padrão C99. Em versões anteriores ao Visual Studio 2019 versão 16.8, não há suporte para o cabeçalho <tgmath.h>. Em todas as versões, não há suporte para as macros pragma CX_LIMITED_RANGE e FP_CONTRACT. Alguns elementos, como o significado dos especificadores de parâmetro em funções de E/S padrão, usam interpretações herdadas por padrão. É possível usar as opções de conformidade do compilador /Zc e especificar as opções do vinculador para controlar alguns aspectos da conformidade da biblioteca.

Arquivos de biblioteca padrão (STL) .lib do C++

Ao criar uma versão de lançamento do projeto, uma das bibliotecas de runtime C básicas (libcmt.lib, msvcmrt.lib, msvcrt.lib) será vinculada por padrão, dependendo da opção do compilador escolhida (multithread, DLL, /clr). Se você incluir um dos arquivos de cabeçalho de biblioteca padrão C++ em seu código, uma biblioteca padrão C++ será vinculada automaticamente pelo Visual C++ em tempo de compilação. Por exemplo:

#include <ios>

Para a compatibilidade binária, mais de um arquivo DLL pode ser especificado por uma única biblioteca de importação. As atualizações de versão podem introduzir bibliotecas dot, DLLs separadas que apresentam uma nova funcionalidade de biblioteca. Por exemplo, Visual Studio 2017 versão 15.6 introduzido msvcp140_1.dll para oferecer suporte a mais funcionalidade de biblioteca padrão sem quebrar a interface binária de aplicativo (ABI) suportada pelo msvcp140.dll. A biblioteca de importação msvcprt.lib incluída no conjunto de ferramentas do Visual Studio 2017 versão 15.6 dá suporte a ambas as DLLs, e o vcredist para essa versão instala ambas as DLLs. Depois de fornecida, uma biblioteca dot terá uma ABI fixa e nunca terá uma dependência em uma biblioteca dot posterior.

Quais problemas poderão ocorrer se um aplicativo usar mais de uma versão do CRT?

Todas as imagens executáveis (EXE ou DLL) podem ter seu próprio CRT estaticamente vinculado ou podem vincular dinamicamente a um CRT. A versão do CRT, incluída estaticamente ou carregada dinamicamente por uma imagem específica, depende das versões das ferramentas e das bibliotecas com as quais ela foi compilada. Um único processo pode carregar várias imagens EXE e DLL, cada qual com seu próprio CRT. Cada um desses CRTs pode usar um alocador diferente, pode ter layouts de estruturas internas diferentes e pode usar combinações diferentes de armazenamento. Isso significa que memória alocada, recursos CRT ou classes passadas através de um limite de DLL podem causar problemas no gerenciamento de memória, uso estático interno ou interpretação de layout. Por exemplo, se uma classe é alocada em um DLL, mas transmitida para e excluída por outra, qual desalocador CRT será usado? Os erros causados podem variar de sutis ao imediatamente fatal e, portanto, a transferência direta de tais recursos não é recomendada.

Você pode evitar muitos desses problemas usando tecnologias da ABI (Interface Binária de Aplicativo), pois elas são projetadas para serem estáveis e têm controle de versão. Projete suas interfaces de exportação DLL para passar informações por valor ou para trabalhar na memória que é transmitida pelo chamador, em vez de alocada localmente e retornada ao chamador. Use técnicas de marshaling para copiar dados estruturados entre imagens executáveis. Encapsule os recursos localmente e só permita a manipulação por meio de identificadores ou funções que você expõe aos clientes.

Também é possível evitar alguns desses problemas, se todas as imagens em seu processo usarem a mesma versão carregada dinamicamente do CRT. Para garantir que todos os componentes usem a mesma versão de DLL de CRT, compile-os usando a opção /MD e use as mesmas configurações de propriedade e conjunto de ferramentas de compilador.

Tenha cuidado se o programa passar determinados recursos de CRT através dos limites da DLL. Recursos como identificadores de arquivo, localidades e variáveis de ambiente poderão causar problemas, mesmo ao usar a mesma versão de CRT. Para obter mais informações sobre os problemas envolvidos e como resolvê-los, consulte Possíveis erros ao passar objetos CRT através dos limites da DLL.

Confira também

Referência da biblioteca de tempo de execução do C
Redistribuindo arquivos do Visual C++