Biblioteca de tempo de execução do Microsoft Visual Studio ~ C / C ++ ~ Vinculação estática / dinâmica

Eu sou um usuário do Microsoft Visual Studio. Minha pergunta é sobre o “C / C + + Runtime Library”.

Eu criei um “Projeto Vazio” com um arquivo fonte “.cpp” “main.cpp” contendo o seguinte código:

#include  int main(void) { std::cout << "Hello World" << std::endl; return 0; } 

“iostream é um arquivo de header que é usado para input / saída na linguagem de programação C ++. É parte da biblioteca padrão C ++.”

  1. Existe uma diferença entre “Biblioteca de tempo de execução C / C ++” e “Biblioteca padrão C / C ++”?

  2. Como sei se a biblioteca “C / C ++ Runtime Library” está estaticamente ou dinamicamente vinculada ao projeto?

  3. Como eu sei onde esta biblioteca está localizada no sistema de arquivos?

  4. No caso, a “Biblioteca de Tempo de Execução C / C ++” é dinamicamente vinculada ao projeto, como posso saber qual “.dll” é usado e onde o “.dll” usado está localizado no sistema de arquivos?

  5. Suponha que eu vincule estaticamente a “Biblioteca de tempo de execução C / C ++” ao projeto, posso ter certeza de que o executável gerado a partir do código-fonte funcionará em todas as plataformas Windows (XP / Vista / Seven / …, 32 bits / 64 pouco)?

  6. Quais são as vantagens / desvantagens de vincular dinamicamente a “Biblioteca de Tempo de Execução C / C ++” ao projeto?

  7. O “C / C ++ Runtime Libray” deve ser estaticamente ou dinamicamente vinculado ao projeto?

Obrigado por suas respostas.

O termo “C / C ++ Runtime Library” não significa nada, é aproximadamente o nome de uma configuração de projeto no IDE. Projeto + Propriedades, C / C ++, Geração de Código, Configuração da Biblioteca de Tempo de Execução. Lá você pode escolher entre / MD e / MT.

Com / MD, a configuração padrão, seu programa estará usando a versão DLL das bibliotecas de tempo de execução. Na sua máquina, eles foram copiados em c: \ windows \ system32 e / ou c: \ windows \ syswow64 pelo instalador do Visual Studio. E você tem cópias deles no subdiretório vc / redist do diretório de instalação do VS, para você usar quando você cria um instalador para o seu programa. Três versões deles, x86 para processadores Intel de 32 bits, x64 para processadores Intel de 64 bits e arm para processadores ARM. Escolha o caminho certo com base na plataforma selecionada em seu projeto.

Os nomes relevantes da DLL são:

  • msvcr110.dll: a biblioteca de tempo de execução C (memcpy et al)
  • msvcp110.dll: a biblioteca padrão do C ++ (std :: string et al)
  • vccorlib110.dll: a biblioteca de tempo de execução para aplicativos da Windows Store
  • vcomp110.dll: a biblioteca de tempo de execução para o OpenMP (consulte #pragma omp)
  • atl110.dll: a biblioteca de tempo de execução para projetos do ATL
  • mfc110 * .dll: bibliotecas de tempo de execução e localização para projetos do MFC
  • vcamp110.dll: a biblioteca de tempo de execução para projetos de AMP

Em sua máquina, você também tem as compilações de debugging dessas DLLs, copiadas para o diretório do Windows pelo instalador do VS. Eles têm o mesmo nome com a letra “d” anexada. Útil apenas para depurar seu código, você não pode redistribuí-los. A configuração da biblioteca de tempo de execução correspondente é / MDd.

A maioria dos projetos C ++ só precisa de msvcr110.dll e msvcp110.dll, você saberia quando optar por usar as outras bibliotecas, já que existem modelos e configurações de projetos específicos para elas.

Uma maneira simples de obter todas essas DLLs instaladas na máquina do usuário é usar o instalador pré-criado. Você pode baixá-lo daqui (nota: atual somente a partir de hoje, isso pode mudar quando um service pack ou atualização se torna disponível). Ou você pode simplesmente copiá-los no mesmo diretório que o seu EXE principal.

Você pode evitar tomar uma dependência nessas DLLs alterando a configuração da biblioteca de tempo de execução para / MT. Nesse caso, o código de suporte de tempo de execução é vinculado ao seu programa e você terá apenas um único EXE para implantar. Obviamente, ele ficará maior quando você fizer isso, às vezes de forma significativa, especialmente quando você usa o MFC.

Usando / MT é arriscado se você criar DLLs, bem como um EXE. Você vai acabar com várias cópias do CRT em seu programa. Isso foi especialmente um problema com versões anteriores do VS, onde cada CRT teria seu próprio heap, não tanto com o VS2012. Mas você ainda pode ter problemas de tempo de execução quando tiver mais de uma variável “errno”, por exemplo. Usar o / MD é altamente recomendado para evitar essa perda.

Seu programa será executado no Windows Vista, 7 e 8. O suporte para XP está diminuindo, você precisará do VS Update 1 e alterará a configuração do conjunto de ferramentas no projeto de “v110” para “v110_xp” para criar um programa que ainda roda no XP . Alguma funcionalidade é perdida quando você o faz, associada ao local e ao armazenamento local do encadeamento, o teste é necessário.

aqui vai nada … por favor, ligue se você encontrar um erro.

1. Existe uma diferença entre “C / C ++ Runtime Library” e “C / C ++ Standard Library”?

sim e não. às vezes as pessoas usam biblioteca de tempo de execução para significar tudo e ignoram completamente a biblioteca padrão (para ferramentas da microsoft). no entanto, tecnicamente, a biblioteca de tempo de execução é carregada no tempo de execução, portanto, inclui o par .lib (import lib) e .dll. veja aqui para mais detalhes: http://msdn.microsoft.com/pt-br/library/vstudio/abx4dbyh(v=vs.100).aspx

tecnicamente, o libc * são bibliotecas padrão e o * crt são bibliotecas de tempo de execução.

2. Como posso saber se a biblioteca “C / C ++ Runtime Library” está estaticamente ou dinamicamente vinculada ao projeto?

Se você estiver usando o IDE (VS2010, outros são semelhantes), isso está nas propriedades do projeto:

 - configuration properties - c/c++ - code generation [Runtime Library] 

3. Como sei onde esta biblioteca está localizada no sistema de arquivos?

Os arquivos lib estão no diretório lib de seu diretório sdk (se você instalou um sdk posterior no windows) ou no diretório visual c ++.

4. No caso, o “C / C ++ Runtime Library” é dinamicamente vinculado ao projeto, como posso saber qual “.dll” é usado e onde o “.dll” usado está localizado no sistema de arquivos?

Você pode descobrir quais são usados ​​usando a ferramenta depends. http://www.dependencywalker.com/

As DLLs estão em algum lugar no diretório do Windows. Eles os movem e agora estão em lugares estranhos com manifestos e coisas para acompanhar a versão. Eu não me preocuparia muito com isso. Se você precisa se preocupar com isso, provavelmente há algo errado. Para detalhes: http://msdn.microsoft.com/pt-br/library/windows/desktop/aa375365(v=vs.85).aspx http://en.wikipedia.org/wiki/Side-by-side_assembly

Se isso for uma preocupação, você pode agrupar um pacote redistribuível com o instalador: Diferença entre o Visual Studio Redistributable e o Visual Studio SP1

5. Suponha que eu vincule estaticamente a “Biblioteca de tempo de execução C / C ++” ao projeto, posso ter certeza de que o executável gerado a partir do código-fonte funcionará em todas as plataformas Windows (XP / Vista / Seven / …, 32 bits / 64 bits)?

sim, se você vincular estaticamente, então você está mais seguro em termos de não ser capaz de encontrar a dll. no entanto, isso torna o seu executável maior. Existem outras conseqüências em termos de comportamento … é difícil enumerar, mas a diferença vem do fato de que a biblioteca está em uma dll vs compilada em seu exe.

6. Quais são as vantagens / desvantagens de vincular dinamicamente a “Biblioteca de tempo de execução C / C ++” ao projeto?

por que usar dll:

um tamanho. tamanho exe menor porque todo o material da biblioteca está na dll que supostamente já foram instalados no sistema do usuário, embora isso às vezes não seja verdade.

b – se houver erros no tempo de execução, a Microsoft pode enviar um novo release para o usuário. você não precisa lidar com isso. Se você vincular estaticamente, você tem que empurrar um novo exe para o usuário.

porque não usar dll:

um – muitos problemas com lidando com dll. Se você esquecer de agrupar o redist, muitos problemas podem aparecer.

b – ter mais dlls para carregar e descarregar causa um início e um tempo de saída mais lentos.

provavelmente outras razões que eu não tenha pensado …

7. O “C / C ++ Runtime Libray” deve ser estaticamente ou dinamicamente vinculado ao projeto?

isso realmente depende. Eu pessoalmente prefiro estaticamente vinculado. Eu odeio lutando ao redor procurando o direito redist / dll / etc.