Funktionalität in eine lib auslagern

es wären eh statische libs, die ich einbinde.
ich denke ich habe irgend was in den Einstellungen oder so falsch gemacht.

Ich werde das ganze nun nochmals von vorne machen und Schritt für Schritt die Sachen einbinden und immer sofort von einem externen Testprogramm testen.

Irgend wo mach ich wohl noch was grundlegend falsch, wenn ich eine lib erstelle. Hat wer nen Tipp, wie ich sinnvoll (in Visual Studios) vorgehe, um eine lib so zu gestalten (und so die Konfigurationen zu setzen), dass später keine Probleme (vor allem Linker-Probleme) auftauchen, wenn sie von einem anderen Projekt eingebunden werden (auch auf hinsicht von meinem Problem oben, von libs die in der lib eingebunden werden).
Über google habe ich noch nichts sinnvolles gefunden, was mir half.

Ich sehe es schon als wichtig an, dass ich dies lerne gut zu beherrschen, sonst werden Kollegen immer Probleme haben, wenn ich libs baue.

Der aus dem Westen ...

Xenya schrieb:

Hat wer nen Tipp, wie ich sinnvoll (in Visual Studios) vorgehe, um eine lib so zu gestalten (und so die Konfigurationen zu setzen), dass später keine Probleme (vor allem Linker-Probleme) auftauchen, wenn sie von einem anderen Projekt eingebunden werden (auch auf hinsicht von meinem Problem oben, von libs die in der lib eingebunden werden).
Über google habe ich noch nichts sinnvolles gefunden, was mir half.

Das Design ist schon die halbe Miete.

Statische *.LIBs sind dann gut, wenn du nicht vorhast, selbst was am Quellcode zu verändern oder keine Erweiterungen brauchst, damit das Programm funktioniert. Damit sparst du dir das Suchen und Einladen von DLLs, weil du immer nur diese Version gebrauchen musst.

Eine dynamische Bibliothek ist vor allem bei häufig zu patchenden Anwendungen zu gebrauchen. Anstatt dass du einen Oschi von einer *.EXE mit einer noch gewaltigeren *.EXE überschreibst, löschst du mit vielen kleinen DLLs genau die Fehler aus, die du willst, lässt aber andere Bibliotheken und *.EXEn in Ruhe.

Visual Studio kann dir da kaum helfen, das bist alles du. Ich würde aber Verweise auf Verweise auf DLLs vermeiden, das verwirrt nur. Sorge lieber dafür, dass deine Bibliotheken von einer Anwendung geladen werden. Bei der statischen Variante brauchst du dich nur darum zu kümmern, dass die *.LIB zur Kompilierzeit vorhanden ist, bei DLLs muss zusätzlich die miterstellte DLL zur Laufzeit zur Verfügung stehen.

weicher

Hallo Xenia,

so weit ich weiss, werden lib's nicht gegeneinander gebunden. Der Linker wird ja nur zum binden der *.exe aufgerufen. Die a.lib .. d.lib sind also nicht in MeineLib.lib enthalten.

Versuch mal folgendes:

MeineLib.h

#pragma comment(lib,"a")   
#pragma comment(lib,"b")   
#pragma comment(lib,"c")   
#pragma comment(lib,"d")   
#pragma comment(lib,"MeineLib")

Eventuell musst Du noch den Pfad zu den einzelnen Lib's angeben

#pragma comment(lib,"c:\\MeineLibs\\ThirdPartyLibs\\a")

diesen Header includest Du dann in Deiner Testapplikation, damit werden alle benötigten Libs in die *.exe der Applikation eingebunden.

Herzliche Grüsse
Walter

weicher schrieb:

so weit ich weiss, werden lib's nicht gegeneinander gebunden. Der Linker wird ja nur zum binden der *.exe aufgerufen. Die a.lib .. d.lib sind also nicht in MeineLib.lib enthalten.

das heißt ich kann es gar nicht so machen, dass ich eine Funktionalität so "zusammenpacke", dass in einem anderen Projekt dann nur noch diese lib eingebunden werden muss? Ich muss also von jedem der es verwenden will verlangen, dass er die anderen libs auch mit in sein Projekt einfügt?
Oh man, gefällt mir nicht so
Ich bin wohl zu Java verwöhnt und wollte es auch nun so konfortabel wie möglich machen, dass Funktionalitäten die von mehr Projekten benötigt wird, alle schön eigenständig sind, so dass sie ohne viel Probleme und Aufwand in allen Projekten eingebunden werden können. Dachte sowas kann ich mit libs machen.

weicher schrieb:

#pragma comment(lib,"c:\\MeineLibs\\ThirdPartyLibs\\a")

Ja, so hat es funktioniert, dass er zumindest kompiliert.
Aber nun kommt die Meldung, dass eine .dll dieser lib nicht gefunden wurde (wenn ich es nicht mit pragma comment mache, sondern die lib direkt in den Projekteigenschaften einbinde, kommt das gleiche).
Anscheinend doch eine .dll (oben meinte ich ja, dass alles statische .dll - ist mir bis jetzt nicht aufgefallen, da ich nur eine .lib einbinde).

Habe von den Projekteingenschaften und Einbindungen nun alles von dem alten Programm, wo die Funktionalität mit drin war, in meine lib kopiert aber die Fehlermeldung geht nicht weg. weiß auch wo die .dll liegt aber selbst in dem Projekt wos funktioniert hat, wird niergends darauf verlinkt.
Alles relevante dürfte so gut wie gleich sein zwischen dem alten Projekt in der die Funktionalität funktionierte und meiner neu erstellten lib - ja der Unterschied ist im großen und ganzen nur, dass es eine statische lib ist und das andere nicht, liegts daran?
Wie muss ich die .dll bekannt machen?

Am liebsten würde ich die ganzen .libs die ich in meiner lib einbinde auflösen und direkt in das Projekt schreiben. Das geht aber leider nicht.

Kann mal kurz erklären was das für libs sind:
Mit einem externen Programm (das hier in der Firma verwendet wird), kann man xml-Schemas bauen. Zur Kommunikation über C++ erstellt es 4 Visualstudios Projekte mit der Darstellung des XML-Schemas (die Projekte die es erstellt sind statische libs).
Diese 4 libs machen grad auch gar keinen Ärger.
Dazu muss noch eine weitere lib eingebunden werden, das Hauptprogramm für die XML-libs. Das ist das Projekt, dass mich grad in den Wahnsinn treibt. Diese lib ist anscheinend eine .dll und die wird nicht gefunden.

Vielleicht hilft euch die Information was, um mein Problem zu erkennen.

Danke

Xenya schrieb:

.
Diese 4 libs machen grad auch gar keinen Ärger.
Dazu muss noch eine weitere lib eingebunden werden, das Hauptprogramm für die XML-libs. Das ist das Projekt, dass mich grad in den Wahnsinn treibt. Diese lib ist anscheinend eine .dll und die wird nicht gefunden.

Wie der aus dem Westen schon gesagt hat: Beim Erstellen einer DLL wird auch eine LIB erstellt. Die LIB musst du zur Kompilierzeit angeben, dafür brauchst du zu diesem Zeitpunkt keine DLL. Aber die DLL muss zur Laufzeit des Programmes vorhanden sein, sonst wird das nix.

Glühbirne schrieb:

Xenya schrieb:

.
Diese 4 libs machen grad auch gar keinen Ärger.
Dazu muss noch eine weitere lib eingebunden werden, das Hauptprogramm für die XML-libs. Das ist das Projekt, dass mich grad in den Wahnsinn treibt. Diese lib ist anscheinend eine .dll und die wird nicht gefunden.

Wie der aus dem Westen schon gesagt hat: Beim Erstellen einer DLL wird auch eine LIB erstellt. Die LIB musst du zur Kompilierzeit angeben, dafür brauchst du zu diesem Zeitpunkt keine DLL. Aber die DLL muss zur Laufzeit des Programmes vorhanden sein, sonst wird das nix.

Ja das klingt logisch.

Als Systemvariable liegt der Ordner der .dll unter der Variable Path aber nicht vor (habe auch keine Adminrechte, dass ich ihn hinzufügen könnte).
Das heißt, irgend wo in den Projekteinstellungen des alten Projektes muss festgelegt sein, wo er die .dll finden kann - sonst würde dieses Programm ja auch nicht gehen. Finde die Einstellung aber nicht.

Ich habe die .dll-Datei einfach mal in einen Ordner geworfen, der in der Path-Variable vorhanden war. Dann ging es auch - zumindest bis er einmal ein Objekt erstellen wollte, dass dort implementiert ist. Dann kommt ein Laufzeitfehler, wegen einer Zugriffsverletzung beim Lesen an Position 0x00000000.

Der aus dem Westen ...

Xenya schrieb:

Ich habe die .dll-Datei einfach mal in einen Ordner geworfen, der in der Path-Variable vorhanden war. Dann ging es auch - zumindest bis er einmal ein Objekt erstellen wollte, dass dort implementiert ist. Dann kommt ein Laufzeitfehler, wegen einer Zugriffsverletzung beim Lesen an Position 0x00000000.

Hört sich eher so an, als ob ein Fehler in der DLL ist. Wenn er startet, ist das ein gutes Zeichen, das zeigt, dass die *.LIB eingebunden und die DLL gefunden wird.

Du solltest die DLL npch einmal debuggen.

Habe mittlerweile herausgefunden, wie die dll beim anderen Code geladen wird. Der code wird von einer Entwicklungsumgebung aufgerufen. In diesen Ordner haben die einfach die dll reingeworfen. Da das Programm auch in dem Ordner wo es ausgeführt wird nach dll-Dateien sucht, findet er sie.

Dass er versucht auf den Speicher 0 zuzugreifen liegt nicht an der .dll würd ich sagen. Vom anderen code aus geht es mit dieser dll ja wunderbar, ohne abzustürzen.

Genaueres zu dem Problem:
Bin mit dem Debugger durch. Er ruft eine Methode in einer der statischen Bibliothken auf. Dort versucht er ein Objekt einer Klasse die wohl in der .dll implementiert ist auf dem Stack zu erstellen. Der Debugger springt da nicht rein (da es eine fremde .dll ist, wird der Debugger die Vorgänge dadrin nicht verfolgen können, weshalb ich nicht verfolgen kann, wo es genau knallt. er kommt auf jeden Fall nicht darüber hinweg, das Objekt zu erstellen).

Ich weiß grad echt nicht weiter. Da löst man ein kleines Problem, freut sich weiter gekommen zu sein und schon kommt das nächste. Ich fang an C++ zu hassen

Aber bei dem Problem werdet ihr mir wohl nicht helfen können, müsstet wahrscheinlich das komplette Projekt sehen.

Ich geh jetzt heim, vielleicht löst sich das Problem ja von allein Übernacht *hust*

Nexus

Bei C++-DLLs musst du gut auf Kompatibilität achten. Also ob die Import-Bibliothek wirklich die richtige ist, ob gleiche CRT-Konfigurationen (C-Runtime) verwendet werden, und vor allem ob die Compiler die gleichen sind.

C-DLLs sind hier etwas flexibler, da das ABI in C standardisiert ist.

weicher

Hallo Xenia,

Ich muss also von jedem der es verwenden will verlangen, dass er die anderen libs auch mit in sein Projekt einfügt?
Oh man, gefällt mir nicht so

Wenn Du für jede Deiner Libraries so einen Header mit den #pragma comment (lib, ...) machst ist das doch kein Problem. Wenn jemand Deine Lib benutzen will, muss er einfach den entsprechenden Header includen und alles ist erledigt.

Ein #pragma comment (lib, ...) kann auch in verschiedenen Headern die gleiche Lib "einbinden" da beisst sich nichts, die Lib wird trotzdem nur eimal zur App gelinkt.

Natürlich müssen die Libraries für jeden Entwickler verfügbar sein.

Da Du #pragma comment(lib, ...) verwendest kannst Du auch in den Properties in VS unter Linker->General Additional Library Directories den Folder mit den Libs angeben, dann kannst Du den Pfad in den #pragma comment(lib, ...) weglassen.

Herzliche Grüsse
Walter

Ich habe nun das Problem gefunden.
Waren ganz versteckte Einstellungen im Projekt.

Vielen Dank für eure Erklärungen, Erfahrungen und Tipps.
Ich glaub, ich habe einiges daraus gelernt und hoffe, dass ich nun besser an die Modularisierung meiner Projekte rangehen kann.

Dass im Hauptprogramm die libs, die ich in den libs verwende auch noch in den zusätzlichen Bibliotheksverzeichnissen stehen müssen, finde ich zwar doof (weil es meist mit verbundenem Ärger für die Anwender der lib verbunden ist) aber ich werde meinen libs immer eine ReadMe beilegen, in denen steht, wass sie alles einbinden müssen.

Nochmals vielen Dank!!!!