Allgemeine Quellcodedateien bei MinGW



  • es gibt #pragma(lib, dateiname) aber ob das unter gcc funktioniert weiß ich nicht

    Kennt weder GCC noch MinGW, afaik nur VS.
    NES-Spieler, nimm DLL's 😉



  • NES-Spieler, nimm DLL's

    Bitte keine Lösungen, die darauf hinauslaufen, daß am Ende etwas völlig anderes als das ursprünglich Geplante realisiert wird.
    Ich meine: DLL-Dateien benutzen oder alles in die Header-Dateien packen kann doch nun wirklich nicht die Lösung sein, wenn es darum geht, allgemeine Klassen und Funktionen bereitzustellen.



  • Warum nicht ?

    Wenn der Quellcode Deklarationen und Definitionen dieser Klassen und Funktionen enthält, dann bekommt der Linker sämtliche Informationen vom Kompiler. Ein Linkerproblem gibt es dann nicht.

    Oder sollten im Quellcode die Definitionen nicht auftauchen ?



  • Im Quellcode schon, aber nicht in den Header-Dateien, ganz einfach deshalb, weil ich das sonst ja auch nicht mache. Normalerweise lagere ich Klassenmethoden in CPP-Dateien aus, da ich eine Klasse, wo die Funktionsdefinitionen drinstehen, ganz einfach unübersichtlich finde. Und mein Programmierstil soll eben nicht davon abhängen, welche Problemchen der Linker hat.



  • Eine CPP lässt sich auch mittels "#include <...>" einbinden :

    (...)
    #include <Funktionen.h>
    #include <Funktionen.cpp> 
    (...)
    

    Das hat den gleichen Effekt, als würde sich Deklaration und Definition in einer Datei befinden.
    Ein Linkerproblem gibt es dann auch nicht.



  • Ach Leute, kommt schon! Was sind denn das für Hackermethoden? Eine CPP-Datei mittels include einbinden.
    Es muß doch irgendwie gehen, lib- (oder a-)Dateien zu einem Programm zu linken, ohne den Dateinamen anzugeben und ohne solche Tricks anzuwenden. Ich meine, was macht man denn, wenn man zum Beispiel DirectX oder SDL programmiert? Dann lädt man doch auch extra Dateien runter, aber ich glaube nicht, daß man dann die entsprechenden (zahlreichen) Binärdateien manuell dazulinken muß. Da schreibt man doch in seinen Code garantiert nur #include <SDL.h> und dann war's das, oder irre ich mich? (Genauso wie ich bei der Benutzung der iostream nicht die libstdc++ dazulinken muß.
    Wenn also jemand weiß, wie die korrekte Vorgehensweise in so einem Fall ist, dann wäre ich sehr dankbar, wenn er es mir sagen würde. Ansonsten: Irgendwelche Tricks und Kniffe im Stil von #include "Quellcode.cpp" sowie Alternativen wie DLL-Dateien brauche ich nicht. Wenn das mein Ziel gewesen wäre, hätte ich auf sowas auch selber kommen können. Aber ich würde jetzt eben gern wissen, wie man es [i]richtig[/] macht.



  • Boah man raffst du das nicht?? Ich habe dir bereits zweimal gesagt, dass du zu linkende Libraries explizit angeben musst. Aber du akzeptierst das anscheinend nicht. Tja, und jetzt fragst du dich bestimmt, wie das SDL und Co. machen? Dazu hat dir bereits nerk und ich indirekt eine Antwort gegeben. Guck doch mal in die <SDL.h> rein, dann weist du wie's gemacht wird. Ja - du ahnst es vielleicht nicht, aber es geht mit pragma-Befehlen und DLLs. Welch Überraschung, nicht?



  • Ich wußte, daß Du Dich jetzt aufregen würdest.

    Du hast mir zwar bereits gesagt, daß man die Dateien explizit mitlinken muß, aber das erklärt immer noch nicht, wieso der Compiler und der Linker offenbar keine Probleme haben, die Standardlibs/mitgelieferten Libs automatisch zu finden. Da ich nicht davon ausgehe, daß die Dateien in den Programmen hardcodiert sind und ich auch nirgendwo eine Datei gefunden habe, in der alle diese Dateien nochmal aufgelistet sind, so daß der Compiler unter Umständen darauf zugreifen könnte, bleibt also immer noch die Frage offen, warum man die mitgelieferten Libs nicht mitlinken muß und ob das dann nicht auch mit externen Libs geht.



  • ist hardcodiert



  • Komisch. Wenn das ganze hardcodiert ist, wieso findet sich dann zum Beispiel die Zeichenkette libdxapi in keiner Datei, außer in der "libdxapi.a" selbst? Müßten in so einem Fall nicht alle a-Dateien irgendwo in den Exe-Dateien genannt werden?



  • NES-Spieler schrieb:

    Komisch. Wenn das ganze hardcodiert ist, wieso findet sich dann zum Beispiel die Zeichenkette libdxapi in keiner Datei, außer in der "libdxapi.a" selbst? Müßten in so einem Fall nicht alle a-Dateien irgendwo in den Exe-Dateien genannt werden?

    das ist compiler magie. fertig. kann sein, dass der compiler sieht, dass das ein ordner in seinem dateiverzeichnis ist und sucht dann bei seinen libs nach ner datei mit demselben namen wie der ordner. oder es gibt irgendwo ne binärdatei, die der compiler liest um zu wissen, welche lib er dazu linken muss, oder es ist wirklich ganz hardcoded. Der standard sagt nichts darüber, wie das geschehen soll.



  • NES-Spieler schrieb:

    Komisch. Wenn das ganze hardcodiert ist, wieso findet sich dann zum Beispiel die Zeichenkette libdxapi in keiner Datei, außer in der "libdxapi.a" selbst? Müßten in so einem Fall nicht alle a-Dateien irgendwo in den Exe-Dateien genannt werden?

    achso ich bezog mich auf libstd++, irgendwas von directx ist da bestimmt nicht fest im g++ codiert. 😉 hab mal in libdxapi reingeschaut, da hab ich gar keine funktionsnamen drin gefunden


Anmelden zum Antworten