#include <iostream>
#include <list>
#include <string>

class obj
{
	public:
		obj() {}
		virtual ~obj() {}
		virtual std::string query( std::string ) /*= 0*/;	// pure virtuelle Funktionen ergeben einen Fehler
		virtual std::string getQuery() /* = 0 */;
	protected:
		std::string res_return;
};

class A : public obj
{
	public:
		A() : i(0) {}
		int i;
		std::string query( std::string q )
		{
			res_return = "Klasse A";
			return res_return;
		}
		std::string getQuery() { return res_return; }
};

class B : public obj
{
	public:
		B() : j(0) {}
		int j;
		std::string query( std::string q )
		{
			res_return = "Klasse B";
			return res_return;
		}
		std::string getQuery() { return res_return; }
};

Zwei KLassen also( A und B ) die von obj erben( somit ist obj eine Schnittstelle für die beiden Klassen ). Soweit so gut. Nun der Bearbeiter der vor die Klassen gesetzt ist und die Befehle an alle Klassen durchgeben soll:

class ChainOfResponsibility
{
	public:
		ChainOfResponsibility( obj*, obj* );
		~ChainOfResponsibility() {}
		bool request( std::string );
	private:
		std::list<obj> *chain  // hier bin ich mir unsicher, std::list<obj*> funktioniert nicht
		std::list<obj>::iterator iter;
};

ChainOfResponsibility::ChainOfResponsibility( obj* ObjA, obj* ObjB)
{
	chain->push_back( *ObjA );
	chain->push_back( *ObjB );
}

bool ChainOfResponsibility::request( std::string test )
{
	for( iter = chain->begin(); iter != chain->end(); iter++ )
	{
		iter->query( "bla" );
		if( iter->getQuery() == test ) return true;
	}
	return false;
}

Und schließlich die main:

int main()
{
	A *a;
	B *b;
	ChainOfResponsibility Ch( a, b );
	if( Ch.request( "Klasse B" ) )
        std::cout << "\"Klasse B\" wurde gefunden" << std::endl;
	else std::cout << "\"Klasse B\" konnte nicht gefunden werden" << std::endl;
}

Fehler:

$ g++ TESTAPP.cpp -o TESTAPP
/tmp/ccLcTqOo.o: In function `obj::obj(obj const&)':
TESTAPP.cpp:(.text._ZN3objC1ERKS_[obj::obj(obj const&)]+0x7): undefined reference to `vtable for obj'
collect2: ld returned 1 exit status

Leider versteh ich die Fehlermeldung nicht so ganz, muss wohl irgendwas mit der list oder der abstrakten Klasse obj zu tun haben, oder? Hat jemand eine bessere Lösung für mich oder gibts irgendwo einen Beispielcode dazu denn Google und die suchfunktion haben mich nicht wirklich weitergebracht .
mfg

Ich habe mich ein wenig mit Design Patterns auseinandergesetzt und bin über "Zuständigkeitsketten" gestolpert...

Das soll jetzt nicht böse gemeint sein: Aber du solltest vielleicht noch einmal ein wenig mehr über die C++ Grundlagen stolpern...

Auma schrieb:

...
virtual std::string query( std::string ) /*= 0*/;	// pure virtuelle Funktionen ergeben einen Fehler
...

Nein! Pure virtuelle Methoden ergeben keinen Fehler. Zumindestens wenn man die Regeln der Polymorphie unter C++ richtig anwendet, und die Klasse als abstrakte Basisklasse dienen soll. Hier hättest du imho schon ein wenig nachforschen müssen, warum es in deinem Programm zu Fehlern kommt.

Grundlegend: Polymorphie funktioniert nur mit Zeigern oder Referenzen! (Falls du von Sprachen wie Java/C# kommst: In anderen Sprachen wie Java und C# sieht man davon nichts, da dort die Zeiger verborgen sind, und deren Referenzen den C++ Zeigern entsprechen).

Ich habe an dieser Stelle noch zwei Anmerkungen:
a) Soll query wirklich eine Kopie des Strings übergeben bekommen, oder reicht nicht auch eine konstante Referenz (Thema: Vermeidung unnötiger Kopien). Diese Frage sollte man sich bei allen nicht-integralen Datentypen stellen...
b) Variablennamen und Bezeichner sollte man immer Sprechend wählen, zudem würde ich sie im Header immer hinschreiben, als Übersicht ist der Header besser als die Sourcedatei geeignet.

Auma schrieb:

...
std::list<obj> *chain  // hier bin ich mir unsicher, std::list<obj*> funktioniert nicht
...

Ähmm... std::list<obj*> funktioniert sicherlich, und es ist eher fraglich warum du die Liste als Zeiger halten willst. Davon abgesehen hält man in der Regel aus guten Gründen keine Iteratoren langfristig. Dies man zwar in einer Liste meist noch gehen, aber ich hoffe du weist das Iteratoren je nach Container zwischenzeitlich ungültig werden können...

Schau dir lieber mal an wo deine Fehler bei "std::list<obj*>" und den pure virtuellen Methoden liegen. std::list<obj> kann nicht klappen, da du dort nur Elemente der Basisklasse halten kannst (Und den restlichen Teil der abgeleiteten Klasse abschneidest).

cu André

asc schrieb:

Nein! Pure virtuelle Methoden ergeben keinen Fehler. Zumindestens wenn man die Regeln der Polymorphie unter C++ richtig anwendet, und die Klasse als abstrakte Basisklasse dienen soll. Hier hättest du imho schon ein wenig nachforschen müssen, warum es in deinem Programm zu Fehlern kommt.

Ja da hast du recht, ich hatte wahrscheinlich eine Fehlermeldung fals gedeutet, danke dafür.

asc schrieb:

Ähmm... std::list<obj*> funktioniert sicherlich, und es ist eher fraglich warum du die Liste als Zeiger halten willst.

Du hast recht in einem vorherigen vcersuch schrieb ich ausversehen std::list<*obj> , jetzt gehts

asc schrieb:

Davon abgesehen hält man in der Regel aus guten Gründen keine Iteratoren langfristig. Dies man zwar in einer Liste meist noch gehen, aber ich hoffe du weist das Iteratoren je nach Container zwischenzeitlich ungültig werden können...

ok, danke für den hinweis, das hab ich noch nicht gewusst

Ich hab einmal versucht alles so zu übernehmen, eine Fehlermeldung bekomme ich noch immer

#include <iostream>
#include <list>
#include <string>

class obj
{
	public:
		obj() {}
		virtual ~obj() {}
		virtual std::string query( std::string& ) = 0;
		virtual std::string getQuery() = 0;
	protected:
		std::string res_return;
};

class A : public obj
{
	public:
		A() : i(0) {}
		int i;
		std::string query( std::string& q )
		{
			res_return = "Klasse A";
			return res_return;
		}
		std::string getQuery() { return res_return; }
};

class B : public obj
{
	public:
		B() : j(0) {}
		int j;
		std::string query( std::string& q )
		{
			res_return = "Klasse B";
			return res_return;
		}
		std::string getQuery() { return res_return; }
};

class ChainOfResponsibility
{
	public:
		ChainOfResponsibility( obj*, obj* );
		~ChainOfResponsibility() {}
		bool request( std::string& );
	private:
		std::list<obj*> chain;
};

ChainOfResponsibility::ChainOfResponsibility( obj* ObjA, obj* ObjB)
{
	chain.push_back( ObjA );
	chain.push_back( ObjB );
}

bool ChainOfResponsibility::request( std::string& test )
{
	std::list<obj*>::iterator iter;
	for( iter = chain.begin(); iter != chain.end(); iter++ )
	{
		iter.query( "bla" );
		if( iter.getQuery() == test ) return true;
	}
	return false;
}

int main()
{
	A *a;
	B *b;
	ChainOfResponsibility Ch( a, b );
	std::string r( "Klasse b" );
	if( Ch.request( r ) )
		std::cout << "Klasse B wurde gefunden" << std::endl;
	else std::cout << "Klasse B konnte nicht gefunden werden" << std::endl;
}

Fehler:

g++ TESTAPP.cpp -o TESTAPP
TESTAPP.cpp: In member function ‘bool ChainOfResponsibility::request(std::string&)’:
TESTAPP.cpp:63: error: ‘struct std::_List_iterator<obj*>’ has no member named ‘query’
TESTAPP.cpp:64: error: ‘struct std::_List_iterator<obj*>’ has no member named ‘getQuery’

hier ist also der fehler, oder?:

iter.query( "bla" );
		if( iter.getQuery() == test ) return true;

ich habs mal so prtobiert, brachte aber nichts:

iter.*query( "bla" );
		if( iter.*getQuery() == test ) return true;

wie kann ich per iterator auf die query Funktion zugreifen?
mfg

(*iter).query

Habe jetzt nicht alles gelesen, aber Iteratoren unterstzützen normalerweise den *-Operator:

(*iter).query

wie waere es mit

iter->query

?

drakon schrieb:

Habe jetzt nicht alles gelesen, aber Iteratoren unterstzützen normalerweise den *-Operator:

(*iter).query

wie waere es mit

iter->query

?

Jo, wollte ich auch noch schreiben, musste aber gerade weg.

wie waere es mit

iter->query

?

habs versucht:

bool ChainOfResponsibility::request( std::string& test )
{
	std::list<obj*>::iterator iter;
	for( iter = chain.begin(); iter != chain.end(); iter++ )
	{
		iter->query( "bla" );
		if( iter->getQuery() == test ) return true;
	}
	return false;
}

Fehler:

g++ TESTAPP.cpp -o TESTAPP
TESTAPP.cpp: In member function ‘bool ChainOfResponsibility::request(std::string&)’:
TESTAPP.cpp:63: error: request for member ‘query’ in ‘* iter.std::_List_iterator<_Tp>::operator-> [with _Tp = obj*]()’, which is of non-class type ‘obj*’
TESTAPP.cpp:64: error: request for member ‘getQuery’ in ‘* iter.std::_List_iterator<_Tp>::operator-> [with _Tp = obj*]()’, which is of non-class type ‘obj*’

mfg

(*iter)->query

oder:

(**iter).query

...habs versucht:

...
{
	std::list<obj*>::iterator iter;
...

Naja, kleiner Denkfehler von Dir:

• ein Iterator zeigt auf ein Listenelement. Deswegen kann man mit '->' bzw. '*' auf ein Listenelement zugreifen.
• in Deiner Liste verwaltest Du aber Zeiger auf Objekte. Willst Du also von einem Listenelement auf das dahinterliegende Objekt zugreifen, brauchst Du wiederum '->' bzw. '*'

Ein Hinwis darauf findet sich tatsächlich in der Fehlermeldung:

Auma schrieb:

...

...List_iterator<_Tp>::operator-> [with _Tp = obj*]()’, which is of non-class type ‘obj*’...

...

Hier brauchst Du also:

(*iter)->query
// iter = "Zeiger auf ein Listenelement"
// (*iter) = Listenelement = obj*
// (*iter)-> = obj

Gruß,

Simon2.

Ich lass das ganze mal durch nen Debugger laufen ...
mfg

Gute Entscheidung.

ja vielen dank jetzt Kompiliert es... leider kommt es zu einem Segmentation fault
Ich lass das ganze mal durch nen Debugger laufen ...
mfg

Dir ist hoffentlich der Fehler an dieser Stelle klar:

ChainOfResponsibility::ChainOfResponsibility( obj* ObjA, obj* ObjB)
{
    chain.push_back( ObjA );
    chain.push_back( ObjB );
}

int main()
{
    A *a; // 1.
    B *b; // 1.
    ChainOfResponsibility Ch( a, b ); // 2.
    //...
}

Ansonsten: Zurück zu den Grundlagen...

1. Uninitialisierte Zeiger sind böse
2. Du kannst doch nicht erwarten das eben diese Zeiger in deiner Liste Sinn machen.

Davon ganz abgesehen solltest du Tips immer ganz oder garnicht beherzigen:

virtual std::string query( std::string& ) = 0;

Soll query den Übergabestring ändern können? Wenn nein, bitte eine konstante Referenz verwenden (Schreibweise: "std::string const &" oder "const std::string &").

Zudem trennt man Code in Deklaration und Definition (Header/Source) und es ist - ich wiederhole nochmal - eine Unsitte im Header die Bezeichner wegzulassen. Stell dir vor du schaust dir deinen Code nach einen halben Jahr nochmal an. Möchtest du für einen Kurzen Überblick wirklich genötigt werden die Implementierung durchzuarbeiten? Man sollte immer gegen die Schnittstelle (Header), nicht gegen die Implementierung programmieren, und daher sollte für das Verständnis der Header ausschlaggebend sein.

class ChainOfResponsibility
{
    //...
    bool request( std::string& );
    //...
}

Was soll diese Methode uns sagen? Ich kann daraus nur ablesen das irgendetwas angefordert wird. Der Bezeichner (da fehlend) gibt nichts her, und auch der Methodenname alleine hilft nicht dabei den Aufruf zu verstehen. Was ich noch ablesen kann ist, das die Methode einen String als Argument erhält, und dieser innerhalb der Methode manipuliert wird (Ansonsten würde ja eine konstante Referenz verwendet werden).

Programme sollten so geschrieben werden das sie möglichst selbsterklärend sind. Wenn du deinen Code nach einen halben Jahr nochmal üerfliegst weißt du wovon ich spreche...

cu André

asc schrieb:

Uninitialisierte Zeiger sind böse

keine Ahnung warum ich das übersehen hab

asc schrieb:

[...]bitte eine konstante Referenz verwenden[...]

das Programm schrieb ich ja nur um das Prinzip besser zu verstehen, aber du hast recht wenn dann richtig
Die Bezeichner spielen somit auch keine Rolle, ich werde das Programm/den Code sicher nicht lange aufbewahren.
mfg

asc schrieb:

[...]bitte eine konstante Referenz verwenden[...]

das Programm schrieb ich ja nur um das Prinzip besser zu verstehen, aber du hast recht wenn dann richtig
Die Bezeichner spielen somit auch keine Rolle, ich werde das Programm/den Code sicher nicht lange aufbewahren.

Der Mensch ist ein Gewohnheitstier. Wenn du dir den Stil früh angewöhnst, wird du ihn auch durchziehen wenn du es wirklich benötigst. Zudem mag das Projekt ein "Wegwerfprojekt" sein, für die anderen Threadleser helfen Bezeichner aber durchaus weiter, selbst wenn du diese nicht benötigst ;)...

cu André