Callbacks per Functor

[matogel]

Hi,
Ich habe ein kleines Problem mit functoren.
Ich habe keine Ahnung, woran das liegen könnte, desshalb hier mal meine implementierung des Functors:

// Functor.h
#ifndef FUNCTOR_H
#define FUNCTOR_H

#include "../Agui_global.h"

namespace Agui
{
	class Functor
	{
	public:
		virtual void operator()() = 0;
	};

	template <class T> class AGUI_EXPORT Callback : public Functor
	{
	private:
		void	(T::*cFunc)();
		T*		cObj;

	public:
		Callback(T* pObj, void(T::*pFunc)());

		void operator()();
	};
}
#endif // FUNCTOR_H

// Functor.cpp

#include "Functor.h"

namespace Agui
{
	template <class T> Callback<T>::Callback(T *pObj, void (T::*pFunc)())
	{
		cObj		= pObj;
		cFunc		= pFunc;
	}

	template <class T> void Callback<T>::operator()()
	{
		(*cObj.*cFunc)();
	}
}

Jetzt lege ich so einen Functor an:

Callback<Core> *callback = new Callback<Core>(this, &Core::buttonPressed);

Diese Zeile liegt in einem anderen Namespace als die definition des Functors (Ich weiss nicht, ob das relevanz hat, desshalb schreib ichs)

Wenn ich das ganze jetzt kompilieren will, wird mir dieser Fehler ausgespuckt:

Core.cpp:173: error: undefined reference to `Agui::Callback<Ryna::Core>::Callback(Ryna::Core*, void (Ryna::Core::*)())'

Ich hoffe, mir kann da wer weiterhelfen.

Wenn noch informationen fehlen, schieb ich die gerne nach ;).

mfg Matogel

[MFK]

Templates nicht in .h/.cpp aufteilen, sondern im Header definieren.

[SeppJ]

Bist du sicher, dass du den Funktor mit new erzeugen möchtest?

[matogel]

Oh, okay
vielen Dank für die schnelle Antwort, das hat mein Problem gelöst.

@SeppJ: ja, da ich keinen Pointer von einer Lokalen variable benutzen möchte, da er auch noch nach ablauf der Funktion benötigt wird.

[pumuckl]

schau dir mal std::function und Lambdas (oder std::bind) bzw. boost::function und boost::bind an, die bieten schon das, was du hier nachzubauen versuchst

[SeppJ]

matogel schrieb:

@SeppJ: ja, da ich keinen Pointer von einer Lokalen variable benutzen möchte, da er auch noch nach ablauf der Funktion benötigt wird.

Du gibst also etwas per new angefordertes aus einer Funktion heraus? Das ist noch ungünstigeres Design als ich befürchtet hatte. Derjenige, der etwas anfordert, gibt es auch wieder frei. Derjenige der für etwas verantwortlich ist, der fordert es auch an. Wechsel von Verantwortung ist zu vermeiden.

[RHBaum]

Achtung OOT:

Das ist noch ungünstigeres Design als ich befürchtet hatte. Derjenige, der etwas anfordert, gibt es auch wieder frei. Derjenige der für etwas verantwortlich ist, der fordert es auch an. Wechsel von Verantwortung ist zu vermeiden.

Hasst Du es gut, wenn Du dass durchsetzen kannst.
Ich beiss mir an sowas mittlerweile die Zähne aus.

Letztlich wieder ne Disskussion mit nem Entwickler:

class IMySuperInterface : public QIrgendwas
{
    Q_OBJECT
public:
    virtual IMyNewIrgendObject * getObjectIrgendwas() = 0;
};

I:
Wasn Das ?
E:
Das nen Interface! sieht man doch. Steht Doch nen I davor

....

I:
Was macht das "getObjectIrgendwas" genau ?
E:
Na das erzeugt nen Object und gibts Dir sieht man doch.
I:
Was meinst du mit erzeugen ?
E:
na anlegen ...
I:
Wie statsich oder dynamisch
E:
Na statisch geht da ja wohl ned
I:
Ok, wenigstens was, du legst das also aufn Freestore an, Wie lange lebt denn das Ding ?
E:
na solange wie man das brauch
I:
Ist das referenzgezählt ?
E:
keine Ahnung
I:
Wer zerstört denn das ?
E:
Na das zerstört sich selber ?
I:
WIe zerstört sich selber ???
E:
Na das sieht man doch, steht doch gross drann, das ist nen QObject! Hasst du denn gar keine Ahnung ?
I:
Aber trotzdem musst du doch wissen, wenn sich das Ding zerstört ?
E:
Neeee muss man nicht, das ist doch der Witz dran, deswegen isses ja nen QObject.

????

Und das ist ehrlich kein Witz.
Sowas krieg ich als Interface, und zwar ueber DLLs (Plugins ! ) hinweg vorgesetzt !.
Und klar weiss ich, das sich bei der QT das "Child" Object zertört, wenn sich das "Parent" sofern man es ned selber macht
Aber Interface-fähiges Design iss es ja wohl ned ^^

[SeppJ]

Dann hilf mit, die frohe Botschaft zu verkünden! Vielleicht kann matogel noch errettet werden, bevor er bei dir als Entwickler anfängt.

Und danke für die amüsant zu lesende Aufzählung der Nachteile .

[Zeus]

RHBaum schrieb:

class IMySuperInterface : public QIrgendwas
{
    Q_OBJECT
public:
    virtual IMyNewIrgendObject * getObjectIrgendwas() = 0;
};

QNightmare