Vererben von Zeiger auf andere Klasse

drakon

Das schreit ja förmlich nach Runtime Errors.

Du solltest dir nochmal die Unterschiede der Zusammenhänge von Klassendefinitionen und den Zusammenhängen von tatsächlichen Objekten zu Gemüte führen.
Wenn du so Sachen machst, hast du Garantiert früher oder später Memory Leaks.

Code-Walker

War klar, an sowas halte ich mich 3 Stunden auf ..., typisch für mich! Tausenden Dank, es funktioniert ja tatsächlich mal

Den unterschied kenne ich, nur arbeite ich noch nicht lange mit der Welt des OOP, es fällt mir noch schwer um zu denken, ich hoffe das ich mich bald dran gewöhnen werde! So wie der Code ist sollten dort doch eigentlich keine memory Leaks auftauchen?

Ich benutze ja lediglich zeiger, und ich füge keine neuen hinzu darum muss ich sie ja nur am ende des Programmes löschen ...

drakon

Code-Walker schrieb:

Ich benutze ja lediglich zeiger, und ich füge keine neuen hinzu darum muss ich sie ja nur am ende des Programmes löschen ...

Was du im gezeigten Code nicht machst. Aber es geht ja nicht um triviale Programme. Sobald das ganze ein wenig grösser wird hast du die aber bestimmt Leaks, keine Angst..

asc

Code-Walker schrieb:

...und habe versucht OOP in mein Kopf zu bringen...

Vielleicht mit zuviel Gewalt und zu wenig beiseite schieben von C-Angewohnheiten. Ich stelle bei dir auch immer wieder fest das du Zeiger extrem liebst.

Es wäre vielleicht einfacher wenn du jetzt mal ohne Code versuchen würdest in möglichst einfachen Worten das zu beschreiben was du eigentlich machen willst. Ich befürchte das man ansonsten sehr weit aneinander vorbei redet.

Aber ich versuche mich mal in meiner Glaskugel:

1. Grundlagenwissen Objekt/Instanz versus Klasse
Eine Klasse stellt im wesentlichen eine Schablone oder ein Oberbegriff dar, und nichts konkretes. Wenn du 2 konrete Anschriften hast, verfügen beide zwar über die gleiche Art von Eigenschaften (Straße, Hausnummer...), die konkreten Werte sind aber für sich genommen völlig voneinander unabhängig. Eine Klasse sagt nur was die Eigenschaften sind, die konkreten Objekte/Instanzen sind aber an sich eigenständig. Wenn Eigenschaften/Methoden von Klassen nicht Instanzbezogen sondern über alle Instanzen der Klasse einheitlich sein sollen, müssen diese mit static deklariert werden.

2. Vererbung "ergänzt" um Aspekte, ändert aber nichts an Regel 1.
Wenn du nun Personen- und Firmenadressen von der Anschrift ableitest, teilen sie diese zwar die Eigenschaften, nicht aber die Werte. Somit kann dein Code auch nicht funktionieren.

Ohne Zeiger, aber sonst gleich:

R mR;
A mA; // hat zwar die Eigenschaften von R, nicht aber dessen konkreten Werte
B mB; // hat zwar die Eigenschaften von R, nicht aber dessen konkreten Werte

Wenn du willst das sich Instanzen gegenseitig kennen solltest du statt dessen diese über Methodenaufrufe etc. Bekannt machen.

Nehmen wir mal einen CD-Spieler: Dieser kann eine CD aufnehmen, und diese Abspielen, sprich, er sollte die CD kennen.

class CDSpieler
{
  //...
  private:
    CD* cd;
  public:
    void Einlegen(CD* cd) { this->cd = cd; }
    CD* Auswerfen() { CD* cd = this->cd; this->cd = NULL; return cd; }
    void Abspielen(); // hier cd verwenden...
  //...
};

int main()
{
  CDSpieler cdspieler;
  CD cd("Das Ich");

  cdspieler.Einlegen(&cd);
  cdspieler.Abspielen();
  //...
}

Code-Walker

Mhh, knapp vorbei

Was ich versuche ist mein gelerntes Wissen in DX und OpenGL in einer Engine zu packen, dadurch brauche ich nicht jedes mal alles neu sschreiben und mein Eigentlicher Cod wird sehr viel übersichtlicher. Außerdem finde ich ist der Lern erfolg größer wenn man sich neben dem lernen noch eine Engine zusammen bastellt. Ich habe nicht vor eine Perfecte Engine zu bauen, und auch keine die mit Ogre oder Irrlicht mithalten kann, sondern eine die für meine zwecke reciht und worauf ich stolz sein kann. ich möchte den Code so aufbauen das ich jeder zeit neue Sachen hinzu fügen kann, und bearbeite/abändern/löschen. Da es leider so üblich ist, das ich von hier und dort ma das und dies brauche, möchte ich das alle klassen aufeinander zugreifen können. Der ablauf, das rendern der Dreiecke, soll alles im Hintergrund geschehen. Es ist finde ich auch ziehmlich blöd das wenn ich für jede funktion die ich aufrufe zeiger auf meine klassen als parameter mitschcken muss. Darum sollen die Klassen bei dich intern die anderen gleich mit abgespeichert haben, man legt sie einmal an und gut ist! Ich mache mal ein kleines UML Digramm (ich glaube das nennt man so) machen, um zu zeigen wie diese Engine aufgebaut sein soll.

Code-Walker

Hier mal ein Diagram:

http://www9.picfront.org/picture/tCqzv9NKu/img/xyxxz.png

Also, von der Main aus, kann ich auf alle klassen zugreifen, bis auf die unterklassen der Gui. Die Scene kann nun auf die ganzen File Formate zugreifen, da die Scene sie zeichnet. Ich möchte aber, das der benutze der Engine (das bin ich), die Objekte in seiner eigenen main datei erstellt. Ein Code um das ganze au der main zu machen könnte dann in etwa so aussehen:

RoolKlasse Root = new RootKlasse();
	FensterKlasse Fenster = new FensterKlasse();
	SceneKlasse Scene = new SceneKlasse();
	FileKlasse File1 = new FileKlasse();
	FileKlasse File2 = new FileKlasse();

	Root->Fenster = Fenster;  // zeige Root wo mein fenster Objekt ist
	Root->Scene = Scene;  // Zeige Root wo mein Scenen Objekt ist

	Fenster->Erstelle("Name", 800, 600); // Erstele mein fenster
	Scene->Erstelle(Fenster); // Auf Welches fenster soll die Scene?

	File1->Lade("blub.obj");    // lade datei
	File2->Lade("blaaaa.obj");  // lade andere datei

	Scene->Hinzufügen(File1);  // zeige wo File1 Objekt ist
	Scene->Hinzufügen(File2);  // zeige wo File2 Objekt ist

	File1->Zeigen(); // Objekt beim rendern anzeigen
	File2->Zeigen();  // Objekt beim rendrn Anzeigen

ist es jetzt verständlich was ich vor habe, und ist dafür der Grundaufbau der Engine so wie er im moment ist am besten geeignet? Was ich halt möchte ist das der benutzer direkt das geladene Objekt oder die Scene selbst zugreifen kann, und nicht über root, root hat halt nur einen zeiger auf da Objekt!

queer_boy

nun, das sieht in der tat eher nach potentiellen memory-leaks aus.
schau dich mal nach dem RAII (Resource Acquisition is Initialization) idiom um.
eventuell auch nach smart-pointern.

btw. aus deiner grafik wird man nicht besonders viel schlauer, da nicht klar ist, wer was braucht - und so grob gefragt: warum muss ein Scene-objekt wissen, dass seine daten aus einer datei kommen?

Code-Walker

Nein, das Scene Objekt hat lediglich einen zeiger au ein Objekt, welches zuvor eine Datei geladen hat.

Code-Walker

Wenn ich das jetzt richtig verstanden habe, ist RAII, wenn man die Zeiger in der Klasse im Destructor einfach löscht. ich hatte mir darunter jetzt so einen riesen großen algorythmus vorgestellt^^

asc

Code-Walker schrieb:

Was ich versuche ist mein gelerntes Wissen in DX und OpenGL in einer Engine zu packen, dadurch brauche ich nicht jedes mal alles neu sschreiben und mein Eigentlicher Cod wird sehr viel übersichtlicher.

Wie wäre es, wenn du erst einmal die GRUNDLAGEN lernen und verstehen würdest?

Code-Walker schrieb:

Außerdem finde ich ist der Lern erfolg größer wenn man sich neben dem lernen noch eine Engine zusammen bastellt.

Mit Sicherheit nicht, dazu fehlt dir nämlich noch reichlich Grundlagenwissen. Wie wäre es wenn du die Messlatte erst einmal etwas niedriger ansetzt, und zu deiner Engine zurückkehrst wenn du auch wirklich verstehst was du schreibst?

Code-Walker schrieb:

Da es leider so üblich ist, das ich von hier und dort ma das und dies brauche, möchte ich das alle klassen aufeinander zugreifen können.

Sehr schlechtes und wenig durchdachtes Design.

Code-Walker schrieb:

Der ablauf, das rendern der Dreiecke, soll alles im Hintergrund geschehen. Es ist finde ich auch ziehmlich blöd das wenn ich für jede funktion die ich aufrufe zeiger auf meine klassen als parameter mitschcken muss.

Das ist aber sowohl üblich wie auch in der Regel der sinnvollste Weg. Das was du wiederum willst ist das Prinzip der Objektorientierung vorne und hinten zu brechen, und auch die Wiederverwertbarkeit massiv einzuschränken (Wegen sehr starken Bindungen).

Das was deine Beschreibungen naheliegen ist im wesentlichen eine Einführung globaler Variablen (in anderen Gewand), starke Implementierungsabhängigkeit und starke Kopplung.

cu André

Code-Walker

Ich habe mir Ogre und Irrlicht angesehen, und Ogre hat ein ähnliches Design ...