list in object klasse die objectklasse auflisten kann

hallo

ich hab eine liste in einer objektklasse
class OBJECT
{
public:
list<OBJECT*> m_component;
};

wie kann ich in m_component OBJECT hineinpuschen?
wie man andere klassen hineinpuscht hab ich hinbekommen.(also mit list<anotherclass> m_component;

mach ich das aber so list<OBJECT*> m_component;
meckert er rum das die OBJECT klasse nich definiert ist.

geht ja nur darum das ich ein object im spiel habe und ne liste brauche in der nune weitere objecte von der OBJECTklasse definiert sind.

davie

ein bisschen mehr code&info&genaue fehlermeldung wären nicht schlecht.
sicher, dass

liste.push_back (new OBJECT);

nicht funktioniert?

ich bin wohl doch nicht so doof mit n bissel überlegung hab ich das jetzt was ich will.

#include <stdio.h>
#include <conio.h>
#include <list>
using namespace std;

class FOO 
{ 
public:
	FOO(){};
list<FOO*> fooList;

int Data; 
}; 

FOO foo;
list<FOO*>::iterator it;

class FOOMGR
{
public:
	void add();
	void show();
	void del(int integer);
};

void FOOMGR::add()
{
	foo.fooList.push_back(new FOO);
	it=foo.fooList.end();
	it--;
	(*it)->Data=55;
	foo.fooList.push_back(new FOO);
	it=foo.fooList.end();
	it--;
	(*it)->Data=66;
	foo.fooList.push_back(new FOO);
	it=foo.fooList.end();
	it--;
	(*it)->Data=100;
}
void FOOMGR::show()
{
	it=foo.fooList.begin();
	while(it!=foo.fooList.end())
	{
		printf("WERT von Foo->Data:%i\n",(*it)->Data);
		it++;
	}
}
void FOOMGR::del(int integer)
{
	it=foo.fooList.begin();
	while(it!=foo.fooList.end())
	{
		if(integer==(*it)->Data){
			printf("lösche WERT von Foo: %i\n",(*it)->Data);
			it=foo.fooList.erase(it);
		}
		it++;
	}	
}
int main(){
FOOMGR fmgr;
fmgr.add();
fmgr.show();
fmgr.del(100);
fmgr.show();

getch();
return 0;
}

wenn man das prog ausführt werden 3 ints in FOO eingefügt. ein int in der mitte gelöscht.
danke für den denkanstoß..dann hol ich mir jetzt kaffe und bau mein objectbaum auf

najagut
durch den übereifer löschte ich das zuletzt eingetragene...funzt aber trotzdem aus der mitte löschen

davie

achtung: bevor du ein element aus der liste löschst, musst du zuerst das mit new erzeugte Objekt mittels delete löschen
also zb

list<Foo*>::iterator i = liste.begin();
delete *i;
liste.erase(i);

danke für den Hinweis

operator void

Und genau deshalb sollte man in STL-Container lieber boost::shared_ptr (www.boost.org) verwenden.

T-Sam[Hawk] schrieb:

it=foo.fooList.end();
	it--;

War es nicht illegal, einen von list::end zurückgegebenen Iterator zu dekrementieren? Ich hatte das so in Erinnerung, habe aber keinen Standard und in der MSDN wird es sogar im Beispiel direkt getan.

Hallo,

operator void schrieb:

War es nicht illegal, einen von list::end zurückgegebenen Iterator zu dekrementieren?

wenn ich es richtig wiedergebe: der Standard fordert für Sequence-Container nur, daß der von end zurückgegebene Iterator-Typ mindestens der Kategorie "forward iterator" angehören muß. Ein "forward iterator" muß aber nach Standard keinen "--"-Operator implementieren (widerspricht ja der Vorstellung eines "forward iterator"), deshalb kann dies in diesem Sinne tatsächlich nicht zulässig sein. Sollte die Implementierung einen "bidirectional" oder "random"-Iterator für end zurückgeben, dann ist die Dekrementierung des erhaltenen Iterators eine gültige Operation. Also kann man sich im allgemeinen nicht auf die Dekrementierung des "end-Iterators" verlassen.

MfG

davie

also ich hab im Standard nichts, was darauf hinweist gefunden.
list unterstützt bidirektionale iteratoren (23.2.2/1) und einige beispiele zeigen --liste.end() sowie ++liste.rend(), das als --current definiert ist (current ist der unter reverse_iterator liegende iterator, protected und --current als side effect angeführt)
damit hätten alle implementierungen denk ich ziemliche probleme.

habe das nochmal durchdacht, ich glaube, ich habe mit der Mindest-Anforderung "forward iterator" nur die Mindest-Anforderung für STL-Sequence-Container allgemein wiedergegeben, eine list erfüllt also diese Bedingung durch die Unterstützung bidirektionaler Iteratoren, wie es auch unter 23.2.2/1 steht, problemlos, alles ok also...

MfG