GUI(Qt) <-(trennen)->NichtGuiKlassen(Qt)

[AlexanderKiebler82]

Hi, =)

Ich würde mich dafür interessieren, wie man
mit qmake -project folgendes erreicht:
-ich habe 4 Dateien:

Datei1: GUI.h
Datei2: GUI.cpp

Datei3: NichtGUI.h
Datei4: NichtGUI.cpp
-------------------------------------------------
->GUI.h includiert NichtGUI.h
->Die Implementierung von GUI.h in GUI.cpp
benötigt Methoden aus den Klassen welche in NichtGUI.h definiert
und NichtGUI.cpp implementiert sind.
--------------------------------------------------
GUI.h<----#include---<NichtGUI.h

Will ich das Programm nun übersetztn, benötige ich ein
#include <NichtGUI.cpp>
in der Datei2 (GUI.cpp).
Dieses include würde ich gerne vermeiden.
----------------------------------------------------
Die Lösung habe ich mir folgender Maßen vorgestellt:

Wie kann ich mit qmake zuerst die NichtGUI dateien compilieren (nicht linken),
Dann die GUI dateine compilieren,
Und sie dann gegeneinander linken ???
Ich bin der Auffassung, dass das mein Problem lösen würde.

Ich hoffe auch darafu verzichten zu können, Methoden als extern deklarieren zu müssen.

Gruß Alex
=)

[-=Freaky=-]

Will ich das Programm nun übersetztn, benötige ich ein
#include <NichtGUI.cpp>
in der Datei2 (GUI.cpp).

wenn die deklarationen im header (NichtGui.h) sind, sollte da der header includiert sein.
... oder hab ich was ueberlesen?

mfg,
julian

[AlexanderKiebler82]

Danke für die schnelle antwort.

Natürlich ist in beiden Dateien
GUI.cpp und NichtGUI.cpp
ein jeweiliges Include für die entsprechenden Header
also
in GUI.cpp ist ein #include "GUI.h"
sowie
in NichtGUI.cpp ein #include "NichtGUI.h"

Das Problem ist, daß die klasse welche in GUI.h definiert ist,
ein objekt der klasse welche in NichtGUi.h definiert ist
erstellt. Der compiler meckert bei jedem Funktionsaufruf =(.
Nur wenn ich die beiden *.cpp Dateien ineinander includiere,
läufts fehlerfrei. Das will ich aber nicht, weil ich finde dass es unsabuer ist.

Gruß Alex

[franzf]

Eigentlich brauchst du für die korrekte "Anwendung" deiner Klassen nur den Header. Die Symbole bastelt der linker dann alle korrekt zusammen. Wenn also dein "NichtGUI.cpp" in der Variable SOURCES steht, sollte doch alles passen.

[AlexanderKiebler82]

Ja der Meinung bin ich auch. Aber er tut es nicht. Irgendetwas habe ich falsch gemacht und ich komm nicht drauf.
Die SOURCES stimmen und die angaben für die header auch.
Die NichtGui.cpp hat ja die GUI.h includiert. Da stehen alle Prototypen.
Die Implementierungen braucht er doch garnicht. Funktionspointer haben doch alle die gleiche größe.
??????????
Na ja ev. komm ich moren weiter, wenn der Kopf wieder freier ist.

Er meckert z.B.:

GLDraw.o||In function `GLDraw::DrawSceneEdgesNDB()':|
GLDraw.cpp:(.text+0xc2)||undefined reference to `WingedEdge<long double>::getlistptrE()'|


Gruß

[franzf]

GRR!
Dein Beispiel ist ja ein template, da gehört die Implementierung in den Header! Der Compiler will ja wissen, welchen Code er generieren muss!

Im übrigen solltest du schauen, möglichst keine Header im Header zu includieren, und statt dessen auf forward declarations zurück zu greifen.

[AlexanderKiebler82]

Verdammt ja.
Das passiert mir immer wieder.
Danke dir.

Du meinst ich soll den Header der NichtGui Klasse in der GUI klasse nicht includieren, sondern ne forwärtsdekleration benutzen ??
Was ist der vorteil ??

Gruß

[franzf]

1) Bei einem #include <> wird der includierte Header vom Compiler geparst. Das schließt parsen von dort includierten Headern ebenfalls ein. Das kostet bei jedem #include unnötig Zeit und Prozessorzeit.
Wenn du die Implementierungen konsequent in den *.cpp schiebst, brauchst du nur mitteilen dass ein "Typ MeineKlasse" existiert, und dafür reicht die forward-declaration.
-> Geschwindigkeitsvorteil beim Kompilieren!

2) Es ist manchmal notwendig (auch wenn es als schlechter Stil verschrien ist) dass 2 Klassen voneinander abhängen, also Typ1 eine Membervariable auf einen Typ2 braucht, aber ebenso Typ2 einen Member auf Typ1. Dann hast du ein Problem, wenn jeweils schon im einen Header der Header der anderen Klasse includiert wird... (Kannst es ja mal ausprobieren)
-> forward-declaration einzige Möglichkeit, das Problem zu lösen.

[AlexanderKiebler82]

Na ja ich Kenne das Problem *lach* (Problem 2). Es tritt auch in diesem Projekt auf, wird bereits
so gelöst wie du es beschrieben hast. Ich kenne es aber nicht als
Möglichkeit 1 zur beschleuningung der compilierungszeit. Das ist mir neu.
Das werde ich mir meken.
Persöhnlich mag ich die forwärtsdekleration sehr gerne, da sie mich an
Prototypen aus C erinnert. Und C ohne Prototypen ist wie schlagsahne ohne Zucker =)

Danke für die schnelle Hilfe.
1.) Hinweis dass meine Klasse ein Template ist hat das Problem gelöst.
(Auch wenn ich am Quelltext nichts verändert habe)
2.) Danke für Erweiterung der Kenntnisse for using forwarddecleration