C++ Libary

DuffCola

Mitglied
Hallo,
ich habe mir eine kleine auf SFML basierende Game Engine geschrieben,
die ich jetzt natürlich bei kleinen Spielen verwenden will.
Ich habe nur was Bibliotheken angeht nicht die geringste Ahnung, ich weiß auch nicht wirklich den unterschied zwischen einer statischen und dynamischen Bibliothek und was es da sonst noch so gibt.
Die Bibliothek selber ist eigentlich nicht so das große Problem(Da findet man schnell Tutorials), aber mein Problem ist, dass die Engine ja SFML benötigt, und ich weiß nicht wie ich SFML in eine Bibliothek einbinden kann, und das die Engine dann auch noch auf anderen PCs funktioniert.

Ich hoffe jemand kann mir da ein paar Tipps geben.
 
Hallo DuffCola,

das kommt auch immer ein wenig darauf an, wie du deine Libraries verwenden willst.

Eine statische Library wird zur Link-Zeit fest mit deinem Programmcode zu einem großen Executable zusammen gebunden. D.h. sollte sich nachträglich an der SFML etwas ändern und sei es nur ein kleiner Bugfix musst du deine Applikation immer neu aus den Sourcen kompilieren.

Bei einer dynamischen Library werden die Funktions/Methoden-Aufrufe die in die SFML Library oder deiner Library erfolgen erst zur Laufzeit aufgelöst. D.h. sollte ein Bugfix für eine deiner Libraries erscheinen reicht es, wenn du die alte Library mit der neuen ersetzt. Ein neu kompilieren deiner Applikation die die entsprechende Library verwendet ist dann nicht von nöten.

Gruß,
Wolf
 
OK danke, das hielft mir schon weiter.
Ist eine DLL eigentlich nur mit C++ CLI verwendbar, oder ist eine dll Platform unabhängig?
Und woraus besteht überhaupt eine Bibliothek?
(Ich finde in einer Bibliothek immer lib und header files(OOP Prinzip ist mir kla).
Muss ich die CPP Dateien einfach ihrgendwie zu einer lib datei umwandeln oder wie ist das?
 
Eine Library ist nur eine Sammlung von Klassen die bereits mit einem Compiler für die entsprechende Plattform übersetzt wurden und vom jeweiligen Archiver zu einer Bibliothek zusammengefasst wurden. Dass heisst eine .dll ist nicht platformunabhängig. Zumal .dll auch glaube ich rein Windows spezifisch ist.

Die Plattformunabhängigkeit in dein SFML Bibliothek bezieht sich darauf, dass sie keinen Code enthält der nur unter einer bestimmten Vorraussetzung von einem Compiler übersetzbar ist. Also zum Beispiel keinen Code der rein Windows spezifisch ist, wie die Verwendung der Funktion CreateThread aus der Windows API. Du musst die Library aber trotzdem noch neu kompilieren, solltest du zum Beispiel dein Programm auf einer HW mit anderem Prozessor und damit anderem Befehlssatz ausführen lassen wollen.

Das ist ja auch der Grund, warum zum Beispiel in Java alles in diesen Byte-Code übersetzt wird und man eine Java VM für sein jeweiliges System benötigt in der der Byte-Code während der Ausführung in den entsprechenden Maschinen-Code übersetzt wird, während bei C++ Compilern immer direkt der native Code erstellt wird.

Gruß,
Wolf
 
Zuletzt bearbeitet:
Hallo,
noch einen Nachtrag bzgl. dlls. Wenn man eine Bibliothek nutzt bekommt man sie meist statisch (mit *.lib und *.h) und dynamisch (*.dll, *.lib und *.h) zumindest unter Windows. Unter Linux sind soweit ich das in Erinnerung habe (*.a und *.h). Dabei gibt es noch diverese Abwandlungen etc, darauf möchte ich jetzt nicht eingehen.
Wenn du nun kompilierst wird ja dein Code den deine Header definieren gesucht und in den *.libs gefunden. Je nachdem ob du statisch oder dynamisch linkst wird der Code in den *.dlls ausgelagert oder direkt in die *.exe gepackt wie Der Wolf oben schon sagte.

Dazu noch ein Anwendungsbeispiel. Dlls lohnen sich vorallem da, wo mehrere Instanzen eines Programms genutzt werden, weil so jede *.dll nur einmal geladen wird. Linkst du jedoch statisch musst du jedes mal die gesamte Anwendung laden, was ggf. viel Speicher kosten kann (abh. von deiner Anwendung, und ob sie mehrfach gestartet werden kann/darf). Z.B macht Windows das fast ausschließlich so, siehe den Haufen dlls im Windows/system32-Ordner.
 
Ja, DLL ist nur Windows (wenn man Sachen wie Wine mag weglässt (Projekt mit dem Ziel,
Win-Programme auf Linux auszuführen))

Allerdings gibt es in Windows noch verschiedene Arten von DLLs,
die zwar alle "dll" heißen, aber verschiedene (nicht zusammenpassende) Sachen drin haben.
Es gibt zB. eine Art für .NET (C#, C++CLI..., ähnliches Bytecodeprinzip wie bei Java),
aber die, die hier interessant sind, sind die rein nativen (für Sprachen wie C/C++...)

Vergleichbares gibt es auch für zB. Linux, nur da ists keine DLL
und auch innen etwas anders aufgebaut.

Wie der Wolf schon schrieb, SFML selbst ist C/C++-Code,
der so geschrieben ist, dass er für beide Betriebssysteme funktioniert.
Will man SFML auf Windows verwenden, wird es eben mit und für Windows
mit einem passenden Compiler kompiliert und ergibt windows-artige Libraries,
auf Linux mit Linuxcompiler bekommt man Linuxtaugliches.

Zu der Sache mit den Dateiarten (hat mit OOP nicht direkt was zu tun)
(hier nur für Windows/VS/nativ):

Eine statische Library ist, wie schon oben gesagt wurde, dazu gedacht,
beim eigentlichen Programm alles mit in die Exe zu packen.
Der Code der Lib besteht aus cpp/h, kompiliert zu lib/h.
Die H-Datei ist eine normale H-Datei eben,
und die Lib enthält die vorkompilierten Cpps.
Beim Hauptprogramm merkt der Compiler durch die H-Datei der Library,
was er in der Lib-Datei hat, und zusammen mit dem kompilierten Hauptprogramm
kommt der Inhalt der Lib-Datei dann in die Exe.
Zum Starten reicht dann die Exe.

Dynamische Libraries haben zusätzlich noch eine Dll.
H ist wieder eine H-Datei,
die Lib enthält diesmal kein kompiliertes Irgendwas, nur etwas Hilfe zum Kompilieren,
und die DLL hat den eigentlichen Inhalt.
Wenn alles fertig ist wird bei jedem Programmstart der Teil aus der DLL neu aus ihr geladen,
muss also auch vorhanden sein.
 
Zurück