web-dev-qa-db-fra.com

Microsoft Visual Studio ~ Bibliothèque d'exécution C / C ++ ~ Liaison statique / dynamique

Je suis un utilisateur de Microsoft Visual Studio. Ma question concerne la "bibliothèque d'exécution C/C++".

J'ai créé un "Projet vide" avec un fichier source ".cpp" "main.cpp" contenant le code suivant:

#include <iostream>

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

"iostream est un fichier d'en-tête utilisé pour les entrées/sorties dans le langage de programmation C++. Il fait partie de la bibliothèque standard C++."

  1. Existe-t-il une différence entre "C/C++ Runtime Library" et "C/C++ Standard Library"?

  2. Comment savoir si la bibliothèque "C/C++ Runtime Library" est liée statiquement ou dynamiquement au projet?

  3. Comment savoir où se trouve cette bibliothèque dans le système de fichiers?

  4. Dans le cas où la "bibliothèque d'exécution C/C++" est liée dynamiquement au projet, comment puis-je savoir quel ".dll" est utilisé et où se trouve le ".dll" utilisé dans le système de fichiers?

  5. Supposons que je lie statiquement la "bibliothèque d'exécution C/C++" au projet, puis-je être sûr que l'exécutable généré à partir du code source fonctionnera sur toutes les plates-formes Windows (XP/Vista/Seven/..., 32 bits/64 bit)?

  6. Quels sont les avantages/inconvénients de la liaison dynamique de la "bibliothèque d'exécution C/C++" au projet?

  7. La "bibliothèque d'exécution C/C++" doit-elle plutôt être liée statiquement ou dynamiquement au projet?

c++visual-studiomicrosoft-runtime-library
41
Léa Massiot

Le terme "bibliothèque d'exécution C/C++" ne veut rien dire, c'est à peu près le nom d'un paramètre de projet dans l'EDI. Projet + Propriétés, C/C++, génération de code, configuration de la bibliothèque d'exécution. Là, vous pouvez choisir entre/MD et/MT.

Avec/MD, le paramètre par défaut, votre programme utilisera la version DLL des bibliothèques d'exécution. Sur votre machine, elles ont été copiées dans c:\windows\system32 et/ou c:\windows\syswow64 par le programme d'installation de Visual Studio. Vous en avez des copies dans le sous-répertoire vc/redist du répertoire d'installation de VS, que vous pouvez utiliser lorsque vous créez un programme d'installation pour votre programme. Trois versions d'entre elles, x86 pour 32 processeurs Intel à 2 bits, x64 pour les processeurs Intel 64 bits et armement pour les processeurs ARM. Choisissez le bon en fonction de la plate-forme que vous avez sélectionnée dans votre projet.

Les noms DLL DLL sont:

  • msvcr110.dll: la bibliothèque d'exécution C (memcpy et al)
  • msvcp110.dll: la bibliothèque standard C++ (std :: string et al)
  • vccorlib110.dll: la bibliothèque d'exécution pour les applications du Windows Store
  • vcomp110.dll: la bibliothèque d'exécution pour OpenMP (voir #pragma omp)
  • atl110.dll: la bibliothèque d'exécution pour les projets ATL
  • mfc110 * .dll: bibliothèques d'exécution et de localisation pour les projets MFC
  • vcamp110.dll: la bibliothèque d'exécution pour les projets AMP

Sur votre ordinateur, vous disposez également des versions de débogage de ces DLL, copiées dans le répertoire Windows par le programme d'installation VS. Ils ont le même nom avec la lettre "d" en annexe. Utile uniquement pour déboguer votre code, vous ne pouvez pas les redistribuer. Le paramètre Runtime Library correspondant est/MDd.

La plupart des projets C++ n'ont besoin que de msvcr110.dll et msvcp110.dll, vous savez quand vous choisissez d'utiliser les autres bibliothèques car il existe des modèles de projet et des paramètres spécifiques pour eux.

Un moyen simple d'installer toutes ces DLL sur la machine de votre utilisateur consiste à utiliser le programme d'installation prédéfini. Vous pouvez le télécharger à partir d'ici (remarque: uniquement en date d'aujourd'hui, cela peut changer lorsqu'un service pack ou une mise à jour devient disponible). Ou vous pouvez simplement les copier dans le même répertoire que votre EXE principal.

Vous pouvez éviter de dépendre de ces DLL en modifiant le paramètre Runtime Library sur/MT. Dans ce cas, le code de support d'exécution est lié à votre programme et vous n'aurez qu'un seul EXE à déployer. Il s'agrandira bien sûr lorsque vous le faites, parfois de manière significative, surtout lorsque vous utilisez MFC.

L'utilisation de/MT est risquée si vous créez des DLL ainsi qu'un EXE. Vous vous retrouverez avec plusieurs copies du CRT dans votre programme. C'était particulièrement un problème avec les versions antérieures de VS où chaque CRT obtiendrait son propre tas, pas tellement avec VS2012. Mais vous pouvez toujours avoir de vilains problèmes d'exécution lorsque vous avez plus d'une variable "errno" par exemple. L'utilisation de/MD est fortement recommandée pour éviter de telles pertes.

Votre programme fonctionnera sur Windows Vista, 7 et 8. Prise en charge de XP est en déclin, vous aurez besoin de VS Update 1 et changer le paramètre de jeu d'outils dans le projet de "v110" à "v110_xp" pour créer un programme qui fonctionne toujours sous XP. Certaines fonctionnalités sont perdues lorsque vous le faites, associées aux paramètres régionaux et au stockage local du thread, des tests sont requis.

59
Hans Passant

Ici ne va rien ... s'il vous plaît carillon si vous trouvez une erreur.

1. Existe-t-il une différence entre "Bibliothèque d'exécution C/C++" et "Bibliothèque standard C/C++"?

Oui et non. Parfois, les gens utilisent la bibliothèque d'exécution pour tout dire et ignorent complètement la bibliothèque standard (pour les outils Microsoft). Cependant, techniquement, la bibliothèque d'exécution est chargée lors de l'exécution, elle inclut donc la paire .lib (import lib) et .dll. Voir ici pour plus de détails: http://msdn.Microsoft.com/en-us/library/vstudio/abx4dbyh (v = vs.100) .aspx

Techniquement, les libc * sont des bibliothèques standard et les * crt sont des bibliothèques d'exécution.

2. Comment savoir si la bibliothèque "C/C++ Runtime Library" est liée statiquement ou dynamiquement au projet?

Si vous utilisez le IDE (VS2010, d'autres sont similaires), c'est dans les propriétés du projet:

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

3. Comment savoir où se trouve cette bibliothèque dans le système de fichiers?

Les fichiers lib se trouvent dans le répertoire lib de votre sdk (si vous avez installé un sdk Windows ultérieur) ou dans le répertoire Visual C++.

4. Dans le cas où la "bibliothèque d'exécution C/C++" est liée dynamiquement au projet, comment savoir quel ".dll" est utilisé et où se trouve le ".dll" utilisé dans le système de fichiers?

Vous pouvez déterminer ceux qui sont utilisés en utilisant l'outil dépend. http://www.dependencywalker.com/

Les DLL se trouvent quelque part dans le répertoire Windows. Ils les déplacent et c'est maintenant dans des endroits géniaux avec des manifestes et des trucs pour garder une trace de la version. Je ne m'inquiéterais pas trop de ça. Si vous devez vous en préoccuper, quelque chose ne va probablement pas. Pour plus de détails: http://msdn.Microsoft.com/en-us/library/windows/desktop/aa375365 (v = vs.85) .aspxhttp: // en. wikipedia.org/wiki/Side-by-side_Assembly

Si cela pose problème, vous pouvez regrouper un package redistribuable avec votre programme d'installation: Différence entre Visual Studio Redistributable et Visual Studio SP1

5. Supposons que je lie statiquement la "bibliothèque d'exécution C/C++" au projet, puis-je être sûr que l'exécutable généré à partir du code source fonctionnera sur toutes les plates-formes Windows (XP/Vista/Seven/..., 32 bits/64 peu)?

Oui, si vous établissez un lien statique, vous êtes plus sûr de ne pas pouvoir trouver la DLL. Cependant, cela rend votre exécutable plus volumineux. Il y a d'autres conséquences en termes de comportement ... C'est difficile à énumérer, mais la différence vient du fait que la bibliothèque est dans une dll vs compilée dans votre exe.

6. Quels sont les avantages/inconvénients de la liaison dynamique de la "bibliothèque d'exécution C/C++" au projet?

Pourquoi utiliser dll:

a - taille. taille exe plus petite car tout le contenu de la bibliothèque est dans la dll qui est censée avoir déjà été installée sur le système de l'utilisateur, bien que ce ne soit pas toujours vrai.

b - S'il y a des bogues dans le runtime, Microsoft peut envoyer une nouvelle version à l'utilisateur. Vous n'avez pas à vous en occuper. Si vous liez statiquement, vous devez pousser un nouvel exe vers l'utilisateur.

Pourquoi ne pas utiliser la DLL:

a - de nombreux problèmes avec la gestion des dll. Si vous oubliez de regrouper la redistribution, de nombreux problèmes peuvent apparaître.

b - le fait d'avoir plus de DLL à charger et décharger ralentit le temps de démarrage et de sortie.

Probablement d'autres raisons auxquelles je n'ai pas pensé ...

7. La "bibliothèque d'exécution C/C++" doit-elle plutôt être liée statiquement ou dynamiquement au projet?

Ça dépend vraiment. Personnellement, je préfère les liens statiques. Je déteste me démener pour chercher le bon redist/dll/etc.

20
thang