wird alles richtig gelöscht?

Code-Walker

Also, wenn ich dich richtig verstanden habe, muss ich das so machen:

class Owner
{
public:
	Owner() { }

	virtual ~Owner() 
	{ 
		for(list<Owner*>::iterator i = ListChild.begin();i != ListChild.end(); i++ )
		{
			//(*i)-> ???;
			delete (*i);
		}
	    ListChild.clear();
	}

	virtual void Update()
	{
		for(list<Owner*>::iterator i = ListChild.begin(); i != ListChild.end(); i++)
		{
		  (*i)->Update();
		}
    }

	void AddChild(Owner* child)
	{
		ListChild.push_back(child);
    }

protected:
	list<Owner*> ListChild;
};

Der destructor der Childs werden ausgeführt.

asc

Code-Walker schrieb:

Also, wenn ich dich richtig verstanden habe, muss ich das so machen:

Öffentliche Vererbung sollte immer "ist ein" bedeuten... NiceChild ist ein Owner?

Über das Thema Grundlagen sowie Design hatte ich ja schon einmal etwas gesagt.

cu André

Code-Walker

Ich versuche mich ja grade mit den Grundlagen von OOP mehr vertraut zu machen!

asc

Code-Walker schrieb:

Ich versuche mich ja grade mit den Grundlagen von OOP mehr vertraut zu machen!

Mir ist aber deine Intention noch nicht klar. Bzw. erschließt sich mir noch nicht ganz der Sinn und vor allem nicht deine Benennungen. Trennen wir das Problem erstmal auf, soweit wie ich es verstanden habe:

Du willst irgendwelche Komponenten haben (wenn ich deine Engineüberlegungen zusätzlich mit hereinnehme), die ihrerseits wieder untergeordnete Elemente enthalten können - liege ich mit dieser Einschätzung richtig? (Thema: Entwurfsmuster, konkret Kompositum).

Wenn ja, schau dir mal den Beispielcode im zweiten Link an.

cu André

hustbaer

sieht soweit korrekt aus. das "delete (*i);" passt auch, genau so macht man das (wenn man keine smart-pointer verwendet).

mach dich aber sobalb wie möglich mit smart pointern (z.b. boost::shared_ptr bzw. tr1::shared_ptr) vertraut, die sind wirklich praktisch. ersparen viel ärger und kopfzerbrechen wegen dingen um die man sich nicht wirklich selbst kümmern muss (und sollte).

Code-Walker

Sowas hier meine ich:

http://upload.wikimedia.org/wikipedia/de/2/2d/Kompositum_Objekte.png

Leider ist das bei mir noch ein klein wenig komplitzierter. Manche von den classen sollen singletons sein, zum beispiel die oberste und die zwei unteren sind singletons. Manche von den letzten müssen wiederum auch singletons sein. Dann muss einer der mttleren auf die nachbarn zugreifen können, und die unteren müssen auf manche seine nachbarn zugreifen können ...

Nexus

Du solltest aufpassen, wenn du so viele Abhängigkeiten hast. Es kann schnell mal passieren, dass man sich nicht mehr im Klaren über die Rechte an den Klassen ist oder sonst die Übersicht verliert. Ausserdem kann es gut sein, dass sich die Kompilierzeit erhöht.

Auch die vielen Singletons, die du da verwendest, lassen mich etwas am Design zweifeln...

Code-Walker

Nunja, eigentlich sind die singletos ganz gut. Wenn ich eine camera habe, kannich ja schlecht zwei kameras haben, den auch im spiel hat man keine gespaltene persöhnlichkeit. Und ich brauche ja auch nur ein device, und auch nur ein Fenster.

drakon

Code-Walker schrieb:

Nunja, eigentlich sind die singletos ganz gut. Wenn ich eine camera habe, kannich ja schlecht zwei kameras haben, den auch im spiel hat man keine gespaltene persöhnlichkeit. Und ich brauche ja auch nur ein device, und auch nur ein Fenster.

Du kannst ohne weiteres auch mehrere Kameras haben. Mal an Splittscreen gedacht? Oder eine "virtuelle" Kamera, um etwas zu simulieren?
Fenster sind mehrere auch gut möglich, sowie auch mehrere Devices. (OK. Devices sind mehrere eher selten der Fall, aber das andere macht wirklich Sinn.)

Code-Walker

EDITED::

Sry, hab net nachgedaht was ich schreibe, hab fieber. Was ich meine, ich habe jetzt alles woeit hinbekommen, nur muss wenn ich jetzt ein Mesh lade, dieser wissen, wo die camera ist. Das heißt die child mussen miteinander komunizieren können. Mir würde da nur einfallen, das man sowas wie ein suchdurchlauf macht, aber da muss es doch bestimmt noch bessere möglichkeiten geben?