Ist es möglich, eine statische C++ - Bibliothek (.lib) zu verwenden, die mit Visual Studio 6 in Visual Studio 2008 kompiliert wurde?Kann ich eine Visual Studio 6 -kompilierte statische C++ - Bibliothek in Visual Studio 2008 verwenden?
Ich sollte nicht denken, warum nicht - solange Sie die üblichen CRT-Speicher Grenzen (dh wenn Sie Speicher innerhalb einer Bibliotheksfunktion reservieren, immer aus der Bibliothek frei - durch Aufruf einer Funktion in der lib zu tun) die Befreiung).
Dieser Ansatz funktioniert gut für Dlls mit allen Arten von Compilern kompiliert, statisch verknüpfte Bibliotheken sollten auch in Ordnung sein.
Ja. Es sollte überhaupt keine Probleme geben. Als gbjbaanb erwähnt, müssen Sie auf Ihren Speicher achten, aber VS2008 wird immer noch damit arbeiten. Solange Sie nicht versuchen, CLR (verwalteten) Code damit zu mischen. Ich würde empfehlen, wenn überhaupt möglich. Aber wenn Sie über rohen C- oder C++ - Code sprechen, wird es sicher funktionieren.
Was genau möchten Sie verwenden? (Was ist in dieser Bibliothek?) Haben Sie es schon versucht, aber haben Sie Probleme, oder überprüfen Sie nur, bevor Sie eine Menge Zeit verschwenden, versuchen, etwas zur Arbeit zu bekommen, das gerade nicht?
Ich frage nur, bevor ich eine Menge Zeit verschwende, um es zum Laufen zu bringen. Ich habe eine kompilierte LIB-Bibliothek und nur die Header-Dateien, die notwendig sind, um es zu verwenden, also wäre ich nicht in der Lage gewesen, die ganze Bibliothek –
Sicher wird es funktionieren.
Fragen Sie wo in VS2008 die Referenzen zu codieren?
Wenn ja, gehen Sie zu proj Requisiten -> Linker -> Eingabe auf Konfigurationseigenschaften auf den Eigenschaftenseiten. Suchen Sie nach "zusätzlichen Abhängigkeiten" und codieren Sie dort die .LIB.
Gehen Sie zu Proj-Requisiten -> Linker -> Allgemein und kodieren Sie den libs-Pfad in "Zusätzliche Bibliotheksverzeichnisse".
Das sollte es tun !!
Es gibt Fälle, in denen die Antwort nein ist, als wir von VS6 zu VS2k5 wechselten, mussten wir alle unsere Bibliotheken neu aufbauen, da sich das Speichermodell geändert hatte und die CRT-Funktionen anders waren.
neu zu kompilieren, daher mein Punkt - wenn Sie alle CRT-Aufrufe innerhalb der Bibliothek behalten, dann werden Sie habe keine Probleme. Sogar zwischen dem Mischen von Release- und Debug-Builds. Wenn Sie einen CRT-Fn innerhalb der Lib aufrufen, übergeben Sie den Speicher außerhalb und lassen Sie dann Ihre App manipulieren, erwarten Sie Ärger. Einfache Kapselung ist die Antwort. – gbjbaanb
Während ich verstehe, was Sie für Speicherzuweisungen meinen, hat VS2K5 abgelehnt, unsere VS6-Bibliotheken zu verwenden. Das war vor zwei Jahren, also der genaue Fehler, den es mir gab, kann ich mich nicht erinnern. Wir mussten Code für Bibliotheken aufspüren, die jahrelang nicht neu kompiliert wurden, und sie in VS2K5 neu erstellen. –
Es kommt wirklich drauf an. Stellt die Lib nur 'externe' C '' Funktionen zur Verfügung, wo der Speicher entweder durch direkte Win32-Methoden (CoTaskMemAlloc, usw.) verwaltet wird oder der Aufrufer niemals den vom Angerufenen zugewiesenen Speicher freigibt und umgekehrt? Sind Sie nur auf grundlegende Bibliotheken angewiesen, die sich seit VS 6 nicht wesentlich verändert haben? Wenn ja, sollte es dir gut gehen.
Es gibt 2 grundlegende Dinge zu beachten. Änderungen an globalen Variablen, die von Bibliotheken von Drittanbietern verwendet werden, und Änderungen an der Struktur von Strukturen, Klassen usw., die von diesen Bibliotheken von Drittanbietern definiert werden. Zum Beispiel hat der CRT-Speicherzuordner wahrscheinlich seine versteckten Zuweisungsverwaltungsstrukturen zwischen den zwei Versionen geändert, so dass eine Version der Bibliothek, die einen Speicherbereich zuweist und einen anderen freien Speicherplatz hat, wahrscheinlich einen Absturz verursacht. Wenn Sie C++ - Klassen über die Schnittstelle bereitstellen und sie auf MS-Laufzeitbibliotheken wie MFC angewiesen sind, besteht die Möglichkeit, dass sich das Klassenlayout zwischen VS 6 und VS 2008 geändert hat. Dies bedeutet, dass auf ein Element/Feld zugegriffen wird auf die Klasse könnte auf die falsche Sache gehen und unvorhersehbare Ergebnisse verursachen. Sie werden wahrscheinlich abgespritzt, wenn die .lib MFC in irgendeiner Kapazität verwendet. MFC definiert und verwendet intern Tonnen von Globals, und jeder Zugriff auf MFC-Globals durch die Operationen in der .lib-Datei kann zu Fehlern führen, wenn sich die MFC-Infrastruktur in der Hostingumgebung geändert hat (seit VS 6, BTW hat sich vieles geändert).
Ich habe nicht genau untersucht, welche Änderungen in den MFC-Kopfzeilen vorgenommen wurden, aber ich habe unvorhersehbares Verhalten zwischen MFC/ATL-basierten Klassenbinärdateien gesehen, die in verschiedenen VS-Versionen kompiliert wurden.
Zusätzlich zu diesen Problemen besteht ein Risiko für Funktionen wie strtok(), die auf statischen globalen Variablen beruhen, die in den Laufzeitbibliotheken definiert sind. Ich bin mir nicht sicher, aber ich bin besorgt, dass diese statischen Variablen möglicherweise nicht richtig initialisiert werden, wenn Sie einen Client verwenden, der den Single-Thread-CRT für einen Thread erwartet, der auf dem CRT mit mehreren Threads erstellt wurde. Sehen Sie in der Dokumentation zu _beginthread() nach, um weitere Informationen zu erhalten.
Zwischen VC6, VS2003, VS2005 und VS2008 gab es einige wenige Änderungen. Visual C++ (in VS2005) beendete die Unterstützung für statisch verknüpfte Einzel-Thread-CRT-Bibliothek. Einige aufbrechende Änderungen aufgezählt here und here. Diese Änderungen haben Auswirkungen auf die Verwendung von VC6-Build-Bibliotheken in späteren Versionen.
Ich nehme an, Sie fragen, ob Sie es mit C++ in VS2008 verwenden können, und nicht, ob Sie es aus einer verwalteten Sprache wie C# oder VB.NET aufrufen können? Wenn Letzteres, dann bearbeiten Sie Ihre Frage, um es klarer zu machen. –