C++ Libary umbauen => in DLL packen, CMake nutzen, brauche hilfe, ideen, etc.

pointhi

Erfahrenes Mitglied
Hy, ich bin gründer (und derzeit einziger programmierer) der Libary satpos, die dazu genutzt werden soll um die Satelliten-Positionsberechnung zu vereinfachen. Leider hat sich irgendwie ein config-problem in der projektdatei eingeschlichen weshalb ich die codeblocks datei verwerfen will und nur mit dem source-code richtig und professioneller zu starten (der funktionieren sollte, sonst nehme ich einfach eine leicht ältere version)

Meine Ideen für die Überarbeitung wären dabei:

  • Libary soll in eine DLL eingebunden werden (so wie bei SDL, wo zum kompilieren header-dateien und die .dll notwendig ist. Glaube das SDL eine Dynamische DLL hat)
  • Nutzung von cMake für den Programmsource (Platformunabhängigkeit, erstellen der makefiles/projektfiles)
  • Neue Ordnerstruktur, angelehnt an aktuelle opensource-software

Das Problem ist dass ich noch nie mit cMake gearbeitet habe bzw. es nie funktioniert hat, und DLLs hab ich auch noch nie programmiert.
Das Projekt ist in C++ programmiert, weshalb ich frage wie es mit der umsetzung in eine DLL ausschaut. Kann ich diese DLL mindestens auch von anderen Objektorentierte Sprachen wie Java öffnen, oder bin ich beim einbinden auf C++ beschränkt? Ist es möglich für nicht Objektorentierte sprachen später eine Adaptions-DLL zu schreiben (Objekorentiert auf nicht objektorentiert) um die mölichen Programmiersprachen zu erweitern?

Das ganze umschreiben hat nicht nur libaryspezifische gründe. Ich hab noch immer probleme mit dem einbinden, nutzen, kompilieren von fremden Code der über die standard-libary geht. Mit Code-Blocks konnte ich mir durch die Vorlagen schon viel ersparen, aber z.b. bei OpenGl, QT4,.. werde ich da nicht weit kommen. Das ist also auch ein praktisches Projekt für mich um in die professionelle softwareentwicklung weiter einzusteigen.

Was mir helfen würde wären auch tutorials darüber, aber bitte wenn möglich rein deutsch. Bei längeren englischen fachtexten vergesse oder übersehe ich wichtige infos relativ schnell.

mfg. pointhi

NACHTRAG:

viele open-source projekte nutzen make, wäre das eine sinnvolle erweiterung, oder ein nützlichere alternative zu cmake bei meinem projekt?
 
Zuletzt bearbeitet:
Hi

Glaube das SDL eine Dynamische DLL hat
Es gibt nur dynamische DLLs ("Dynamic Link Library)
a) Die sind ihre eigene Datei

b) Können entweder fix an ein Verwenderprogramm
gebunden werden (indem man die zur DLL gehörende .h-Datei includiert und
die .lib bei den anderen .libs in den Linkereinstellungen dazuschreibt)
Vorteil: Einfach zu verwenden
Nachteil: Das ganze Programm startet nicht, wenn die DLL fehlt

c) oder man kann die DLL "händisch" während der Programmausführung laden
(LoadLibrary...)
Vorteil: Wenn keine DLL da ist, kann man selbst entscheiden, was das Programm macht.
Nachteil: Etwas umständlicher als b.


Die andere Art Library sind die statischen: Bei denen gibts überhaupt keine Dll-Datei.
Nur .lib und .h. Beim Kompilieren werden Verwenderprogramm und die Libraryfunktionen
alle zusammen in eine Exe gepackt.


Ein häufiges Missverständnis noch:
.h und .lib werden immer nur zum Kompilieren benötigt, nicht zum Programmstart.
Man muss sie also nicht weitergeben, wenn der Empfänger
das ganze Programm nur verwenden will.

Das Projekt ist in C++ programmiert, weshalb ich frage wie es mit der umsetzung in eine DLL ausschaut. Kann ich diese DLL mindestens auch von anderen Objektorentierte Sprachen wie Java öffnen, oder bin ich beim einbinden auf C++ beschränkt? Ist es möglich für nicht Objektorentierte sprachen später eine Adaptions-DLL zu schreiben (Objekorentiert auf nicht objektorentiert) um die mölichen Programmiersprachen zu erweitern?
Direkt, wie du es dir vorstellst, kann Java erst mal überhaupt nichts mit DLLs anfangen,
(egal ob Klassen drin sind oder nicht).
Grund: Java macht keine "echten" Programme wie zB. C/C++.
Die class-Dateien haben ihr eigenes Format, und müssen zum Ausführen
erst mal von der JRE verstanden und in Echtbefehle umgesetzt werden.

Es gibt Möglichkeiten, DLLs einzubinden, aber da ist Mehrarbeit nötig,
um eine passende Variante für Java anbieten zu können. Siehe JNI/JNA.


Das Selbe gilt übrogens für C# mit seinem .NET-Framework (entspricht JRE/JDK)
(obwohl die Dateiendungen dort auch Dll und Exe sind der Inhalt ist anders).
Die C#-Tauglichkeit zu erreichen ist aber nicht ganz so umständlich wie bei Java.


Zu den Nicht-Objektorientierten Varianten: Natürlich geht das.
Wenn jemand die DLL zB. in einem reinen C-Programm ohne C++ nutzen will,
freut er sich über das sicher.

Gruß
 
Hi.
Meine Ideen für die Überarbeitung wären dabei:

Libary soll in eine DLL eingebunden werden (so wie bei SDL, wo zum kompilieren header-dateien und die .dll notwendig ist. Glaube das SDL eine Dynamische DLL hat)
Was ist denn eine "dynamische" DLL?
Nutzung von cMake für den Programmsource (Platformunabhängigkeit, erstellen der makefiles/projektfiles)
Gute Idee ;)
Das Problem ist dass ich noch nie mit cMake gearbeitet habe bzw. es nie funktioniert hat, und DLLs hab ich auch noch nie programmiert.
:google: es gab mal eine kurze Einführung in CMake vom linux magazin (online).
Das Projekt ist in C++ programmiert, weshalb ich frage wie es mit der umsetzung in eine DLL ausschaut. Kann ich diese DLL mindestens auch von anderen Objektorentierte Sprachen wie Java öffnen
Nein.
oder bin ich beim einbinden auf C++ beschränkt?
Du bist beim Einbinden von einer DLL (unter Windows) auf eine bestimmte Compilerversion beschränkt. D.h. du mußt eine extra DLL für MSVC 10 und eine für MSVC 2008 und eine für MinGW etc. erstellen.
Ist es möglich für nicht Objektorentierte sprachen später eine Adaptions-DLL zu schreiben (Objekorentiert auf nicht objektorentiert) um die mölichen Programmiersprachen zu erweitern?
Ja, so eine Wrapper-Bibliothek zu schreiben ist möglich.
C++:
class A {
public:
  int foo();
};

extern "C" {
  typedef void* A_PTR;

  A_PTR new_A() {
    return static_cast<A_PTR>(new A());
  }

  int A_foo(A_PTR obj) {
    return static_cast<A*>(obj)->foo();
  }
}
Es gibt mit SWIG :google: ein Tool welches einem viel dieser Arbeit abnimmt.
viele open-source projekte nutzen make
Also alle etwas größeren Projekte nutzen kein Make. Höchstens automake + autoconf + autoirgendwas
wäre das eine sinnvolle erweiterung, oder ein nützlichere alternative zu cmake bei meinem projekt?
CMake ==> (Makefile, MinGW Makefile, NMake Makefile, Code::Blocks, MS VS, ...)
automake ==> GNU Makefile (immerhin relativ plattformunabhänig, aber Windows ist ein Krampf)
make ==> Handarbeit (?)

Gruß
 
b) Können entweder fix an ein Verwenderprogramm
gebunden werden (indem man die zur DLL gehörende .h-Datei includiert und
die .lib bei den anderen .libs in den Linkereinstellungen dazuschreibt)
Vorteil: Einfach zu verwenden
Nachteil: Das ganze Programm startet nicht, wenn die DLL fehlt

Diese Möglichkeit würde ich anstreben


Bei CMake bin ich leicht weiter gekommen, aber ergebnisse hab ich leider keine bekommen, wieder abbruch durch fehlermeldungen.

Dann werde ich mal versuchen eine C++ DLL zu schreiben und zu nutzen.

mfg. pointhi
 
Ich wollte gerade mit dll proggen anfangen, bin dabei auf ein "großes" problem gestoßen. Die DLL soll auch auf Linux kompiliert werden können, weshalb die windows.h schon wegfällt. Ich will nicht anfangen 1000. Ausnahmebedingungen für den Präprozessor schreiben. Auch hab ich nicht gefunden wie ich in Linux die DLLs (.a Dateien) bauen muss.

mfg. pointhi
 
Bei CMake bin ich leicht weiter gekommen, aber ergebnisse hab ich leider keine bekommen, wieder abbruch durch fehlermeldungen.

Ich hab da einfach irgendein opensource-projekt genommen und versucht eine projektdatei zu machen. Bei Visualstudio bin ich viel weiter gekommen, bei Codeblocks MinGw gibts nur noch fehlermeldungen. Ich versteh auch endlich ein wenig das mit den Variablen. Derzeit will ich es jetzt so machen dass ich eine batchdatei ausführe, und diese alle nötigen verzeichnisse cleart, und den compiler, linker, etc. ausführt.
Hab damit auch schon eine dll gemacht, das source-file ware aber nur ein HelloWorld programm ohne irgendwelche änderungen. Ob ich dass einbinden kann ist fraglich.

Hier das aktuelle skript für das compilieren:

Bash:
@echo off

echo Starte Builden von satpos
echo.

# hier wird festgelegt der compilierer definiert

set compiler="C:\Program Files (x86)\CodeBlocks\MinGW\bin\g++.exe"

echo Compilierpfad: %compiler%
echo.

# Leere diverse Verzeichnisse

echo J | del include
echo.

echo J | del obj
echo.

echo J | del bin
echo.

# Kopieren von den Headerdateien in \src nach \include

echo Kopiere Header-Dateien in den Ordner include
echo.
xcopy src\*.h include
echo.

# Hier die eigentliche kompiliersequenz

echo Starte Compilieren
echo.

@echo on

%compiler% -Wall -fPIC -g -c src\*.cpp

@echo off

# Verschieben der *.o Dateien vom Main-Verzeichnis in das dafür vorgesehene verzeichnis \obj
echo.
xcopy *.o obj\*.o /Y
del *.o
echo.

@echo on

%compiler% -Wall -shared -Wl,-soname,satpos.dll.1 -o bin\satpos.dll obj\*.o

@echo off

echo.

# Kopieren der erstellen .dll in den test-ordner

del test\satpos.dll
copy bin\satpos.dll test\satpos.dll

# Fertig
pause

Würde mich über anregungen, kritik, etc. zu diesem skript freuen.

mfg. pointhi
 
Bei CMake bin ich leicht weiter gekommen, aber ergebnisse hab ich leider keine bekommen, wieder abbruch durch fehlermeldungen.
Was hast du gemacht? Wie lauten die Fehlermeldungen?
Derzeit will ich es jetzt so machen dass ich eine batchdatei
:eek: Also zurück in die Computersteinzeit...
Würde mich über anregungen, kritik, etc. zu diesem skript freuen.
Anregungen? Nimm CMake...

Gruß
 

Neue Beiträge

Zurück