webentwicklung-frage-antwort-db.com.de

Microsoft Visual Studio ~ C / C ++ - Laufzeitbibliothek ~ Statische / dynamische Verknüpfung

Ich bin ein Microsoft Visual Studio-Benutzer. Meine Frage betrifft die "C/C++ Runtime Library".

Ich habe ein "leeres Projekt" mit einer ".cpp" -Quelldatei "main.cpp" erstellt, die den folgenden Code enthält:

#include <iostream>

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

"iostream ist eine Header-Datei, die für die Eingabe/Ausgabe in der Programmiersprache C++ verwendet wird. Sie ist Teil der C++ - Standardbibliothek."

  1. Gibt es einen Unterschied zwischen "C/C++ Runtime Library" und "C/C++ Standard Library"?

  2. Woher weiß ich, ob die Bibliothek "C/C++ Runtime Library" statisch oder dynamisch mit dem Projekt verknüpft ist?

  3. Woher weiß ich, wo sich diese Bibliothek im Dateisystem befindet?

  4. Falls die "C/C++ - Laufzeitbibliothek" dynamisch mit dem Projekt verknüpft ist, woher weiß ich, welche ".dll" verwendet wird und wo sich die verwendete ".dll" im Dateisystem befindet?

  5. Angenommen, ich verknüpfe die "C/C++ - Laufzeitbibliothek" statisch mit dem Projekt. Kann ich sicher sein, dass die aus dem Quellcode generierte ausführbare Datei auf allen Windows-Plattformen (XP/Vista/Seven/..., 32-Bit/64) funktioniert? bisschen)?

  6. Was sind die Vor-/Nachteile einer dynamischen Verknüpfung der "C/C++ Runtime Library" mit dem Projekt?

  7. Soll die "C/C++ Runtime Library" eher statisch oder dynamisch mit dem Projekt verknüpft werden?

41
Léa Massiot

Der Begriff "C/C++ - Laufzeitbibliothek" hat keine Bedeutung, er ist ungefähr der Name einer Projekteinstellung in der IDE. Projekt + Eigenschaften, C/C++, Codegenerierung, Einstellung der Laufzeitbibliothek. Dort können Sie zwischen/MD und/MT wählen.

Mit der Standardeinstellung/MD verwendet Ihr Programm die DLL Version der Laufzeitbibliotheken. Auf Ihrem Computer wurden sie in c:\windows\system32 und/oder c:\windows kopiert\syswow64 vom Visual Studio-Installationsprogramm und Sie haben Kopien davon im Unterverzeichnis vc/redist des VS-Installationsverzeichnisses, die Sie verwenden können, wenn Sie ein Installationsprogramm für Ihr Programm erstellen -bit Intel-Prozessoren, x64 für 64-bit Intel-Prozessoren und Arm für ARM Prozessoren. Wählen Sie die richtige basierend auf der Plattform, die Sie in Ihrem Projekt ausgewählt haben.

Die relevanten DLL Namen sind:

  • msvcr110.dll: die C-Laufzeitbibliothek (memcpy et al)
  • msvcp110.dll: die C++ - Standardbibliothek (std :: string et al)
  • vccorlib110.dll: Die Laufzeitbibliothek für Windows Store-Anwendungen
  • vcomp110.dll: die Laufzeitbibliothek für OpenMP (siehe #pragma omp)
  • atl110.dll: Die Laufzeitbibliothek für ATL-Projekte
  • mfc110 * .dll: Laufzeit- und Lokalisierungsbibliotheken für MFC-Projekte
  • vcamp110.dll: Die Laufzeitbibliothek für AMP-Projekte

Auf Ihrem Computer befinden sich auch die Debugbuilds dieser DLLs, die vom VS-Installationsprogramm in das Windows-Verzeichnis kopiert wurden. Sie haben den gleichen Namen, an den der Buchstabe "d" angehängt ist. Nützlich nur zum Debuggen Ihres Codes, Sie können sie nicht weiterverteilen. Die entsprechende Einstellung für die Laufzeitbibliothek lautet/MDd.

Die meisten C++ - Projekte benötigen nur msvcr110.dll und msvcp110.dll. Sie wissen, wann Sie sich für die Verwendung der anderen Bibliotheken entscheiden, da für diese bestimmte Projektvorlagen und -einstellungen vorhanden sind.

Eine einfache Möglichkeit, alle diese DLLs auf dem Computer Ihres Benutzers zu installieren, ist die Verwendung des vorgefertigten Installationsprogramms. Sie können es herunterladen von hier (Hinweis: Aktuell nur ab heute. Dies kann sich ändern, wenn ein Service Pack oder ein Update verfügbar wird.) Oder Sie kopieren sie einfach in dasselbe Verzeichnis wie Ihre Haupt-EXE.

Sie können eine Abhängigkeit von diesen DLLs vermeiden, indem Sie die Einstellung für die Laufzeitbibliothek auf/MT ändern. In diesem Fall ist der Laufzeit-Support-Code mit Ihrem Programm verknüpft und Sie müssen nur eine einzige EXE-Datei bereitstellen. Es wird natürlich größer, wenn Sie dies tun, manchmal erheblich, insbesondere wenn Sie MFC verwenden.

Die Verwendung von/MT ist riskant, wenn Sie neben einer EXE-Datei auch DLLs erstellen. Sie werden am Ende mehrere Kopien des CRT in Ihrem Programm haben. Dies war insbesondere bei früheren Versionen von VS ein Problem, bei denen jede CRT einen eigenen Heap erhalten würde, nicht so sehr bei VS2012. Sie können jedoch immer noch hässliche Laufzeitprobleme haben, wenn Sie beispielsweise mehr als eine "errno" -Variable haben. Die Verwendung von/MD wird dringend empfohlen, um solche Verluste zu vermeiden.

Ihr Programm läuft unter Windows Vista, 7 und 8. Die Unterstützung für XP schwindet, Sie benötigen VS Update 1 und ändern die Toolset-Einstellungen im Projekt von "v110" auf "v110_xp". Um ein Programm zu erstellen, das noch unter XP ausgeführt wird, gehen einige Funktionen verloren, die mit dem lokalen Speicher und dem thread-lokalen Speicher verknüpft sind.

59
Hans Passant

Hier geht nichts ... bitte melden Sie sich, wenn Sie einen Fehler finden.

1. Gibt es einen Unterschied zwischen "C/C++ Runtime Library" und "C/C++ Standard Library"?

Ja und nein. Manchmal verwenden die Benutzer die Laufzeitbibliothek, um alles zu bedeuten, und ignorieren die Standardbibliothek insgesamt (für Microsoft-Tools). Technisch gesehen wird die Laufzeitbibliothek jedoch zur Laufzeit geladen, sodass sie die Paare .lib (import lib) und .dll enthält. Weitere Informationen finden Sie hier: http://msdn.Microsoft.com/en-us/library/vstudio/abx4dbyh (v = vs.100) .aspx

Technisch gesehen handelt es sich bei der libc * um Standardbibliotheken und bei der * crt um Laufzeitbibliotheken.

2. Woher weiß ich, ob die Bibliothek "C/C++ Runtime Library" statisch oder dynamisch mit dem Projekt verknüpft ist?

Wenn Sie IDE (VS2010, andere sind ähnlich) verwenden, finden Sie dies in den Projekteigenschaften:

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

3. Woher weiß ich, wo sich diese Bibliothek im Dateisystem befindet?

Die lib-Dateien befinden sich im lib-Verzeichnis Ihres sdk (falls Sie ein späteres Windows-sdk installiert haben) oder im Visual C++ - Verzeichnis.

4. Falls die "C/C++ Runtime Library" dynamisch mit dem Projekt verknüpft ist, woher weiß ich, welche ".dll" verwendet wird und wo sich die verwendete ".dll" im Dateisystem befindet?

Mit dem Werkzeug "Abhängigkeiten" können Sie herausfinden, welche verwendet werden. http://www.dependencywalker.com/

Die DLLs befinden sich irgendwo im Windows-Verzeichnis. Sie bewegen sie herum und es ist jetzt an unkonventionellen Orten mit Manifesten und Dingen, um den Überblick über die Version zu behalten. Ich würde mir darüber nicht allzu viele Sorgen machen. Wenn Sie sich darüber Sorgen machen müssen, stimmt wahrscheinlich etwas nicht. Weitere Informationen: http://msdn.Microsoft.com/en-us/library/windows/desktop/aa375365 (v = vs.85) .aspxhttp: // en. wikipedia.org/wiki/Side-by-side_Assembly

Wenn dies ein Problem ist, können Sie ein weiterverteilbares Paket mit Ihrem Installationsprogramm bündeln: nterschied zwischen Visual Studio Redistributable und Visual Studio SP1

5. Angenommen, ich verknüpfe die "C/C++ - Laufzeitbibliothek" statisch mit dem Projekt. Kann ich sicher sein, dass die aus dem Quellcode generierte ausführbare Datei auf allen Windows-Plattformen (XP/Vista/Seven/..., 32-Bit/64) funktioniert? Bit)?

Ja, wenn Sie statisch verlinken, sind Sie sicherer, da Sie die DLL nicht finden können. Dies vergrößert jedoch Ihre ausführbare Datei. Es gibt andere Konsequenzen in Bezug auf das Verhalten ... Es ist schwierig aufzuzählen, aber der Unterschied ergibt sich aus der Tatsache, dass sich die Bibliothek in einer DLL befindet und nicht in Ihrer Exe kompiliert ist.

6. Was sind die Vor-/Nachteile einer dynamischen Verknüpfung der "C/C++ Runtime Library" mit dem Projekt?

Warum sollte man dll benutzen:

eine Größe. kleinere exe-größe, da sich das gesamte bibliotheksmaterial in der dll befindet, die angeblich bereits auf dem system des benutzers installiert ist, obwohl dies manchmal nicht zutrifft.

b - Wenn es Fehler in der Laufzeit gibt, kann Microsoft dem Benutzer eine neue Version zur Verfügung stellen. Du musst dich nicht damit auseinandersetzen. Wenn Sie statisch verlinken, müssen Sie eine neue Exe an den Benutzer senden.

Warum nicht DLL verwenden:

a - viele Probleme beim Umgang mit DLL. Wenn Sie vergessen, den Redist zu bündeln, können viele Probleme auftreten.

b - Mehr DLLs zum Laden und Entladen verursachen eine langsamere Start- und Beendigungszeit.

Wahrscheinlich andere Gründe, an die ich nicht gedacht habe ...

7. Soll die "C/C++ Runtime Library" eher statisch oder dynamisch mit dem Projekt verknüpft sein?

Es kommt wirklich darauf an. Ich persönlich bevorzuge statisch verlinkt. Ich hasse es, nach der richtigen Redist/dll/etc zu suchen.

20
thang