spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Also mein GCC hier hat auch bereits windows dlls erstellt, ich weiß grade echt nicht, was ihr meint?!

Du verwendest dann wohl MinGW oder einen anderen Windows Port von GCC. Das tut auch nichts zur Sache, wie bereits gesagt ist jedem klar dass es möglich ist. Es geht darum dass das ein rein compilerspezifisches und nicht portables Features ist...

Ja, ich verwende MinGW, trotzdem bleibts doch dann GCC. Und es hat niemand bereits gesagt, dass es allen klar ist...

Ich hab mir jetzt alle Beiträge nochmal durchgelesen und verstehe jetzt auch, was ihr gemeint habt. Da aber jeder immer nur von dlls im allgemeinen spricht (nur sehr selten von .so, wie es in linux heißt), kann man eure Beiträge auch wirklich falsch verstehen Für mich hat es sich so angehört, als ob ihr glaubt, dass gcc überhaupt nicht in bibliotheken exportieren kann (oder zumindest keine Klassen ).

Dass die dlls (ich spreche wieder von bibliotheksdateien im allgemeinen) aber keineswegs portabel sind, stimmt.

Zitat von »n0_0ne«

Und es hat niemand bereits gesagt, dass es allen klar ist...

Zitat von »dot«

ich bin mir sicher dass der GCC natürlich etwas vergleichbares hat

Zitat von »n0_0ne«

Da aber jeder immer nur von dlls im allgemeinen spricht (nur sehr selten von .so, wie es in linux heißt), kann man eure Beiträge auch wirklich falsch verstehen Für mich hat es sich so angehört, als ob ihr glaubt, dass gcc überhaupt nicht in bibliotheken exportieren kann (oder zumindest keine Klassen ).

Dass die dlls (ich spreche wieder von bibliotheksdateien im allgemeinen) aber keineswegs portabel sind, stimmt.

Wir sprachen nicht von Bibliotheksdateien im allgemeinen sondern von dlls im speziellen. Und wie schon gesagt ging es nie darum ob der GCC jetzt Klassen in dlls exportieren kann, es ist jedem klar (mir zumindest) dass der GCC genau wie MSVC einen Mechanismus dafür hat. Der Punkt ist, um es ein weiteres Mal zu sagen, dass dlls nur Funktionen exportieren können (dlls können nichts anderes, wenn du eine Klasse exportierst dann wird dein Compiler, der ja weiß wie er Klassen auf binary Ebene implementiert, einfach Funktionen exportieren mit denen er was anzufangen weiß). Alles was darüber hinausgeht sind compilerspezifische Dinge. Wenn du mit deinem MinGW eine dll erstellst in die du eine Klasse exportiert hast dann kannst du die Klasse in dieser dll nicht mit einem anderen Compiler verwenden. Dass die dll unter Linux nicht laufen wird ist dabei sowieso klar.

Also die letzten 5 Posts hören sich für mich wie "das Haar in der Suppe suchen an". Um das mal klar darzustellen:

1. Ich denke wir sind uns alle einig das man sowohl unter Windows, Linux als auch Mac Shared Libraries erstellen kann.
2. Unter Windows sind das DLLs, unter Linux *.so
3. Es ist sowohl unter Windows als auch Linux möglich Klassen aus solch einer Bibliothek zu exportieren (im Sinne ich kann die Klasse in meiner einbindenden Anwendung verwenden, nicht das mir da noch einer einen Strick draus dreht.)
4. Das man dafür unterschiedliche Codepfade in bestimmten Bereichen braucht, hat hier niemand ausgeschlossen .

Zitat von »dot«

Zitat von »n0_0ne«

Was genau meinst du mit: exportieren von klassen in dlls geht nur mit microsoft compilern?

Genau das. Dlls unterstützen nur einfache Funktionen. Das Exportieren von kompletten Klassen ist ein Microsoft-spezifisches Feature.

Deswegen empfand ich diese Aussage von dot zu pauschal.

Um auf das "Harr in der Suppe" zurückzukommen: Klassenexport geht, kein grund die Pferede scheu zu machen. Wenn man über die Methode redet wie es geht, dann kann man argumentieren, das es nicht ohne seperate Codezweige geht. Daraus aber zu die Aussage aufzustellen das es nur unter MS geht und nicht unter Linux, weil der Code anders ist, halte ich für irreführend.

My 2 cents.

Thoran

Zitat von »Thoran«

1. Ich denke wir sind uns alle einig das man sowohl unter Windows, Linux als auch Mac Shared Libraries erstellen kann.

Es ging in diesem Thread sowieso nie um was andres als Windows.

Zitat von »Thoran«

3. Es ist sowohl unter Windows als auch Linux möglich Klassen aus solch einer Bibliothek zu exportieren (im Sinne ich kann die Klasse in meiner einbindenden Anwendung verwenden, nicht das mir da noch einer einen Strick draus dreht.)

Weder Linux sos noch Windows dlls bieten einen Weg um Klassen zu exportieren. Wenn eine Klasse exportiert wird dann exportiert der Compiler einfach nur Funktionen mit denen er etwas anzufangen weiß.

Zitat von »Thoran«

4. Das man dafür unterschiedliche Codepfade in bestimmten Bereichen braucht, hat hier niemand ausgeschlossen .

Darum gings auch nie.

Zitat von »Thoran«

Um auf das "Harr in der Suppe" zurückzukommen: Klassenexport geht, kein grund die Pferede scheu zu machen.

Eben nur als compilerspezifisches Feature. Und ein weiteres Mal kann ich mir nur selbst zitieren:

Zitat von »dot«

Der Punkt ist aber dass sowas immer eine rein compilerspezifische Angelegenheit ist. Wenn du mit dem GCC eine dll erstellst in die eine Klasse exportiert wurde dann wirst du diese mit MSVC nicht benutzen können und umgekehrt...

Zitat von »Thoran«

Daraus aber zu die Aussage aufzustellen das es nur unter MS geht und nicht unter Linux, weil der Code anders ist, halte ich für irreführend.

Hab ich auch nie versucht.

Ich denke mal, wir können die Diskussion darüber jetzt abbrechen Das Ganze ging nur von einer falschen Interpretation meinerseits aus und dann haben wir etwas aneinander vorbeigeredet

Es ist mir nur wichtig klarzumachen dass das Exportieren von Klassen in dlls nur eine Komfortfunktion einiger Compiler ist die mit großen Einschränkungen verbunden und absolut gar nicht portabel ist. Solche dlls kann man (im Gegensatz zu "normalen" dlls die man sogar Sprachgrenzen hinweg einsetzen kann) dann nur mit dem selben Compiler verwenden (wenns blöd läuft dann sogar nur mit der selben Version) und üblicherweise wird dabei auch nur loadtime dynamic linking unterstützt und kein runtime dynamic linking...

Damit hätten wir dann wohl klassisch aneinander vorbei geredet. Ich sagte es geht prinzipiell, während du angemerkt hast das dies ausschießlich Compiler-bedingt ist.

Ich denke es wär einfacher gewesen zu diesem Punkt zu kommen, wenn wir uns nicht auf DLLs zur Benennung festgelegt hätten. DLLS sind nämlich etwas was ich persönlich nicht unmittelbar mit GCC assoziere(mir ist MinGW bekannt), aber das ist dann wohl mein Verständnisfehler. Da das ursprüngliche Thema über Windows ging, ist es wohl ist der Fokus auf DLLs klar.

Trotzdem in der Praxis mit msvc und GCC heißt es letzten Endes das man Klassen exportieren kann. Und dass dürften meiner subjektiven Meinung nach wohl die meist verwendetsten Compiler in der PC-Anwendungserstellung sein.

Thoran

Edit: Bei der Austauschbarkeit von Bibliotheken zwischen Kompilern geb ich dir dann recht. Offensichtlich kam ich noch nie in diese Lage, sonst hätte ich diesen Punkt bereits auch schon als schmerhaft empfunden.

Mir war klar dass wir aneinander vorbeirreden, darum hab ich auch so energisch versucht das Missverständnig aufzuklären

Zitat von »Thoran«

Trotzdem in der Praxis mit msvc und GCC heißt es letzten Endes das man Klassen exportieren kann. Und dass dürften meiner subjektiven Meinung nach wohl die meist verwendetsten Compiler in der PC-Anwendungserstellung sein.

Natürlich. Mir gings auch nie darum ob es geht oder nicht sondern darum darauf aufmerksam zu machen dass es sich dabei um eine rein compilerspezifische Komfortfunktion handelt. Zugegeben, mein zweites Posting war dabei etwas irreführend, ich wollte natürlich nicht ausdrücken dass so etwas prinzipiell nur unter MSVC möglich ist sondern dass ihm die so erstellen dlls nur mit MSVC nutzen werden. Im letzten Satz kann man MSVC natürlich auch gegen den bevorzugten Compiler substituieren ohne den Kern meiner Aussage zu verändern: Egal mit welchem Compiler man das macht, die dlls lassen sich dann nur mit genau diesem Compiler verwenden.