[C++] Template-Magie für Signal/Slot-System (geändert)

[Chromanoid]

Hallo Leute,

hier treiben sich ja einige C+-Experten und Template-Magier herum, also riskiere ich mal eine Frage.

Ich habe eine Klasse, die eine Funktionssignatur als Template-Parameter nehmen soll. Also zum Beispiel so:

Code: Alles auswählen

template <typename TFunc> 
class Signal  { };

Signal<void (const Param&)> blaWithFunction;

Jetzt kann ich stressfrei eine Klassenmethode definieren, die einen Funktionszeiger annimmt:

Code: Alles auswählen

void Connect( TFunc* funcPointer ) { ... }

Aber wie drücke ich es aus, dass ich jetzt gern einen Member Function Pointer mit dieser Signatur hätte. So hier geht's jedenfalls nicht:

Code: Alles auswählen

template <typename TClass>
void Connect( TClass* receiver, (TClass::*TFunc) memberFuncPointer);

da hier ja TFunc eigentlich der Name des Parameters ist. Hat jemand eine Idee, wie der Syntax dafür aussehen könnte? Oder bin ich hier völlig auf dem Holzweg und muss mit mühsam kleinteiliger Template-Magie die Funktionssignatur in Rückgabewerte und Parameter zerlegen?

Hm. Wobei sich mir dann die Frage stellt, wie ich die Aufrufparameter dann weiterleiten soll, wenn ich die Anzahl und Typen nicht kenne. Ich glaube, ich habe hier doch mehr Nachholebedarf, als ich mir ursprünglich erhoffte.

Randbemerkung: Eine Eigenimplementation einer Signal-Klasse ist hier nötig, weil a) die Primitive zur Thread-Synchronisierung vorgegeben sind, b) ich unbedingt Scoped Connections haben will, ohne jeden Receiver von irgendwas ableiten zu müssen und c) die gängigen Implementation RIESIG sind. Ich brauche keine Rückgabewerte, Akkumulatoren und den ganzen sonstigen Scheiß. Ich will 0 bis x Klassenmethoden (und nach Möglichkeit auch statische Funktionen) an ein Signal hängen und fertig.

Ich google derweil mal weiter. Vielleicht finde ich eine kleinere fertige Implementation da draußen, die das schon erledigt. Bis dahin schonmal Danke im Voraus!

Bye, Thomas

[Youka]

Bei der Kompilierung einer Source geschieht sowohl für Templates als auch überladenen Funktionen eine Generierung von mehreren Exemplaren (für jeden Template Typ bzw. Funktionsausführung) mit verschiedenen Adressen (spätere Aufrufe werden angepasst), demnach kann es nur am Umgang mit dem übergebenen Parameter liegen.

Übergeben kannst du lediglich Funktionspointer im Scope, weswegen ich hier zu fragen habe, ob deine Memberfunktionen, welche du als Pointer übergeben willst, auch nur statisch sind!

[Eisflamme]

Hm?

Also auf Anhieb würde ich sagen, bei deiner Methodenzeiger-Definition fehlt der Rückgabetyp.

[Eisflamme]

Das hier geht:

Code: Alles auswählen

class ZZ
{
public:
	void test() {std::cout << "Hallöle..\n";}	
};

template<class T>
void Func(T* bla, void (T::*hi)())
{
	(bla->*hi)();
}

int main()
{
	ZZ z;
	Func<ZZ>(&z, &ZZ::test);
}

PS: Das Code-Tag ist nicht so der Hammer oder mach ich was falsch? ^^

[Schrompf]

Danke für die Hinweise, aber das ist leider nicht das Problem, was ich meine. Es geht ja gerade um das Übertragung einer Funktion auf eine echte Klassenmethode, keine statische Funktion.

Ich möchte einen Syntax, der aus einem Funktionszeiger

Code: Alles auswählen

typedef void (*FunkZeiger)(Param1, Param2);

einen Klassenmethoden-Zeiger ableitet:

Code: Alles auswählen

typedef void (Klasse::*Methode)(Param1, Param2);

also quasi Parameter und Rückgabewert überträgt, aber das Ganze zu einer Klassenmethode einer gegebenen Klasse uminterpretiert. Die Klasse würde ich dann als weiteren Template-Parameter rausziehen, aber das ist ein anderes Thema. Das Ziel dahinter ist, dass ich die Parameterliste als Template-Parameter bekomme und daraus dann sowohl einen normalen Funktionszeiger als auch einen Member Function Callback bauen kann.

Überhaupt scheint mir das Ganze ein doch sehr kniffliges Thema zu sein. CppEvent ist z.B. eine weitere fertige Implementation, die sich anfangs sehr interessant las, vor allem wegen des Verzichts auf Herden von fortschrittlichen Features. Aber auch die hat sich dann wieder als brechend voll mit Sonderfällen und Compiler-Workarounds herausgestellt, um da noch einen Zipfel Performance rauszuholen und hier auf einem uralten Compiler zu laufen... das kriege ich nie an meinem Chef vorbei, der schon Templates für den Teufel hält.

Aktuell baue ich mir erstmal eine Minimalversion, ein parameterfreies Signal. Schlimmstenfalls muss ich die paar Klassen dann für ein und zwei Parameter duplizieren, mehr werden hier eh nie nötig sein.

Bye, Thomas

[kristof]

Hi Thomas,
Ich hab vor einiger Zeit auch mal versucht eine eigene Implementierung einer solchen Signal/Slot Klasse zu machen. Ich hab mich allerdings auf einen bzw. keinen Parameter und keinen Rückgabewert beschränkt. Mit dem Ergebnis bin ich auch nicht wirklich zufrieden, aber vielleicht kannst du dir die eine oder andere Anregung davon holen.
Ich muss allerdings dazu sagen, dass ich das nie wirklich auf Herz und Nieren getestet habe und momentan auch nicht mehr einsetze, weil es dann in der konkreten Anwendung irgendwie doch nicht einfacher ist.

[Psycho]

An wem kriegst Du das nicht vorbei?

[kimmi]

Schau mal in die Funktoren der ZFXCE, da haben wir das in dem File TFunctor.h gelöst. Bin gerade etwas in Eile, morgen kann ich da genauer darauf eingehen.

Gruß Kimmi

[Eisflamme]

Für leere Parameter hätte ich schon fast was hinbekommen. Leider funktioniert reinterpret_cast nicht, weil man selbst void* nicht in einen Methodenzeiger konvertieren kann. Sehr seltsam:

Code: Alles auswählen

#include <iostream>

class X
{
};

template<typename A, typename B>
struct Converter
{
	typedef typename A typeA;
	typedef typename B typeB;

	typedef typeA (typeB::*newPtr)();
	typedef typeA (*oldPtr)();

	newPtr operator()(oldPtr p)
	{
		return reinterpret_cast<newPtr>(p);
	}
};


void someFunction() {std::cout << "Test";}

int main()
{	
	void (X::*test)();
	test = Converter<void, X>()(&someFunction);

	X hi;
	(hi.*test)();
}

[dawit]

Ich weiß nicht genau ob ich dich richtig verstanden habe, jedenfalls sieht die Signatur einer Memberfunktion so aus:

Code: Alles auswählen

 return_type (Class::*)(param_type, ...)

// und wird so aufgerufen (wenn mClass eine Referenz auf die Klasse ist, ansonsten ->*)
(mClass.*mFunc)();

EDIT: vielleicht findest du hier was

[Eisflamme]

Er will einen Funktionszeiger zu einem Methodenzeiger konvertieren.

Was mich daran stört, ist nur, dass Du eigentlich den Geltungsbereich der Funktion in die Klasse verschiebst, also etwas, wofür man eigentlich zusätzlichen Code schreiben müsste. Auf deine Weise würde man eine normale Funktion quasi in eine Klasse schieben können. Kannst Du bei boost::signal nicht abschauen? Ich weiß zwar auch nicht, wie die das genau machen, aber ich glaube, die unterscheiden einfach zwischen Funktions- und Methodenzeiger. Damit wäre das natürlich einfach zu lösen. Und die Parameterliste kannst Du evtl. über variadic templates bauen, was natürlich ein "modernes Feature" wäre.

Btw. was hast Du für nen Chef, der Templates für Teufelszeug hält? Das ist meine Meinung nach einer der feinsten Dinge bei C++ überhaupt. oO

[Schrompf]

Die tonangebenden Herrschaften hier halten bereits C++ selbst für eine gewagte Sache. Was bei einer Codebase von 6 Millionen Zeilen AnsiC ja auch in gewissem Maße stimmt. Seid also gnädig zu ihnen.

Methodenzeiger sind natürlich nicht auf void* castbar - Methodenzeiger sind auch doppelt so groß wie normale Zeiger. Das liegt daran, dass auch ein Methodenzeiger noch virtuell sein kann - Du kannst einen Zeiger der Methode der Basisklasse nehmen und der Aufruf wird trotzdem korrekt nach Objekttyp auf abgeleitete Methoden umgeleitet.

Es ging mir ja auch nur um den reinen Syntax. Ich möchte natürlich keinen Funktionszeiger in einen Klassenmethodenzeiger umwandeln. Ich möchte die Parameterliste, die ich als Template-Parameter habe, einmal als Funktionszeiger und einmal als Klassenmethodenzeiger verwenden. Ich habe aber schon gemerkt, dass selbst wenn es dafür eine syntaktische Methode gäbe, dies das kleinste meiner Probleme wäre. Daher jetzt erstmal eine Implementation des Signals ohne Parameter, später vielleicht eine Variante mit einem Parameter. Das dürfte reichen.

[Eisflamme]

Diese Parameterproblematik könnte man evtl. wirklich mit variadic templates in den Griff kriegen. Hab hier aber nur VS2010 Express Edition, das kann das noch nicht...

[Schrompf]

Ich habe mal den Thread-Titel angepasst, weil ich das Thema gern weiterverwenden möchte :-)

Ich möchte gern eine Klasse definieren, die eine C++0x-Lambda-Funktion speichern und zu passender Gelegenheit ausführen kann. Sinn hinter der Aktion ist ein einfaches Delegate-System (vorerst nur ohne Parameter und ohne Rückgabewert), das Member Function Callbacks, normale statische Funktionen und auch C++0x-Lambda-Ausdrücke aufnehmen kann. Dazu definiere ich eine Basisklasse:

Code: Alles auswählen

  class BaseDelegate
  {
  public:
    BaseDelegate() { }
    virtual ~BaseDelegate() { }

    virtual void operator () () = 0; ///< executes the callback, inside of operator() to be compatible with STL functors
    virtual BaseDelegate* Clone() const = 0; ///< creates a copy of the object
  };

und spezialisiere in den Ableitungen für die drei verschiedenen Anwendungen. Die Klasse für Lambda-Ausdrücke beschert mir allerdings ein paar Sorgen:

Code: Alles auswählen

  class LambdaDelegate : public BaseDelegate
  {
  public:
    typedef decltype( []() { } ) LambdaType; ///< type of a lambda expression. "Implementation-defined" according to the standard

    LambdaDelegate( const LambdaType& code) : mCode( code) { }

    void operator () () { mCode(); }
    BaseDelegate* Clone() const { return new LambdaDelegate( *this); }

  protected:
    LambdaType mCode;
  };

Der zentrale Gedanke ist also, dass ich mir den Typ eines Lambda-Ausdrucks (der ja laut Standard nicht spezifiziert ist) als Typedef rausziehe und davon dann eine Kopie speichere. Ich vermute, Lambda-Kram wird nur als anonyme Funktion in die Exe reinkompiliert und der Typ des Ausdrucks ist so ne Art Funktionszeiger. Damit müsste die obige Klasse funktionieren. Leider kann ich das hier nicht nachprüfen, da die Zielplattform noch GCC4.2 verwendet - ich baue das hier sozusagen auf Vorrat, in der Hoffnung, dass die Kollegen noch die Nützlichkeit dieses Manövers erkennen, wenn ich schon ne Weile weg bin.

Klappt das so, wie ich mir das ausgedacht habe?

Bye, Thomas

[Schrompf]

Nuja, den Teil werde ich irgendwann mal daheim erproben müssen.

Anderes Thema: was wäre ein geeigneter Default für einen Template-Parameter, der einen Funktionsparameter beschreibt. Also ein Konstrukt, dass ich als Default an einen Template-Parameter übergeben kann, so dass der resultierende Typ kein Funktionsparameter mehr ist. In folgendem Minimalkonstrukt übernimmt die Methode DoIt() zwei Parameter, deren Typ per Template-Parameter bestimmt werden können. Ich brauche nun ein Konstrukt, dass ich als Templateparameter einsetzen kann, so dass aus der Zwei-Parameter-Funktion eine Ein-Parameter-Funktion wird.

Code: Alles auswählen

template <typename TParam1, typename TParam2 = MAGIC>
void DoIt( const TParam1& p1, const TParam2& p2) { callMe( p1, p2); }

Als Beispiel. Man nehme man, callme() wäre für zwei und für einen Parameter überladen. Was setze ich als MAGIC ein, damit ein "DoIt<Param1>( nurEinParam);" am Compiler vorbeikommt und korrekt die Ein-Parameter-Überladung von callMe() aufruft? Gibt es ein Konstrukt, dass ich als Funktionsparameter einsetzen kann, so dass der Parameter nicht in die Funktionssignatur reinzählt? Oder bin ich hier komplett auf dem Holzweg?

Bye, Thomas

[Schrompf]

Ok, hat sich erledigt. Ich habe irgendwie immernoch die Vorstellung im Kopf, Templates seien irgendne Magie, die magisch erkennt, was ich will.

Template-Funktionsparameter kann man nur per partieller Template-Spezialisierung optional machen. So in dem Stil:

Code: Alles auswählen

struct MyDummyParam
{
  int pffft;
};

template <typename TParam = MyDummyParam>
class Signal
{
  void Emit( TParam param) { listener->Execute( param); }
};

/// Spezialisierte Implementation für den Dummy-Parameter nimmt bei Emit() gar keinen Param mehr
template <>
class Signal<MyDummyParam>
{
  void Emit() { listener->Execute(); }
};

Mal schauen, ob ich einen cleveren Weg finde, wie ich das ohne Variadic Templates kaskadieren kann. Ich suche nämlich nach so einer Möglichkeit, um mir zu ersparen, x Kopien der Signal-Klasse und aller abhängigen Helferklassen rumliegen zu haben.

[CodingCat]

Aber wie drücke ich es aus, dass ich jetzt gern einen Member Function Pointer mit dieser Signatur hätte. So hier geht's jedenfalls nicht:

Code: Alles auswählen

template <typename TClass>
void Connect( TClass* receiver, (TClass::*TFunc) memberFuncPointer);

Ich habe gerade eben das Eingangsproblem dieses Threads eher zufällig beim Programmieren mit etwas Probieren gelöst:

Code: Alles auswählen

struct test
{
   bool method(int a) { return a != 0; }
};

int main()
{
   typedef bool free_function_signature(int);
   free_function_signature test::*mptr = &test::method;
   return 0;
}

Deduzieren von freien Signaturen geht ebenfalls ganz analog:

Code: Alles auswählen

template <class Class, class Signature>
void print_signature(const Class &obj, Signature Class::*method)
{
   std::cout << typeid(Class).name() << std::endl;
   std::cout << typeid(Signature).name() << std::endl;
}

print_signature(test(), &test::method);

Die Syntax hat mich selbst überrascht, geht aber auch im GCC.

Nachtrag: Um dem ganzen doch wieder etwas Magie zu verleihen, hier noch nachträgliche Erkenntnisse:

Code: Alles auswählen

bool free_function(int a) { return test().method(a); }

template <class Class, class Signature>
void use_signature(const Class &obj, Signature Class::*method)
{
   Signature *funptr = &free_function; // error C2440: 'initializing' : cannot convert from 'bool (__cdecl *)(int)' to 'bool (*)(int)'
   typedef Signature deduced_signature;
   deduced_signature *funptr2 = &free_function; // MAGICALLY WORXX!
}

use_signature(test(), &test::method);

Womöglich ein weiterer MSVC Compiler-Bug?

[mnemonix]

Hm, scheint wohl kein Bug zu sein.

Werden die Template-Parameter beim Aufruf der Funktion use_signature weggelassen (Auto-Herleitung), wird Signature (wegen des zweiten formalen Parameters method) zu bool __thiscall(int) ausgewertet (logisch). Bei expliziter Angabe von use_signature<test, bool (int)>(...) kommen keine Compiler-Fehler, da hier die Standard-Aufrufkonvention __cdecl hinzugefügt wird. Die Aufrufkonvention von method wird jedoch durch den Kontext von Class::* wieder in __thiscall umgewandelt. Explizite typedefs in Form von Rückgabetyp __thiscall neuerTyp(Parameter, ...) sind nicht erlaubt (jedoch Zeiger dieser Art), daher wandelt der Compiler die Aufrufkonvention des zweiten Template-Parameters wieder in die Standard-Aufrufkonvention __cdecl. So meine Vermutung. Kann mich auch irren.

Gruß,
mnemonix

[Aramis]

Ich bin mir nicht sicher inwieweit calling-conventions ueberhaupt durch den Standard abgedeckt sind. Der Standard nennt den Begriff selber nur ein Mal, also eher nicht (nicht zuletzt sind MSVCs und gcc's jeweilige Syntaxen fuer calling-conventions ja auch reichlich krude).

Wir bewegen uns also in jedem Fall im Bereich implementation-dependent. Solce Erweiterungen sind generell zulaessig, aber die ueblichen Regeln der Sprache duerfen dabei nicht verletzt werden. Fuer typedefs gilt nunmal die Identitaet

Code: Alles auswählen

typedef TheType OldType;
typeid(TheType*)==typeid(OldType*); // nicht genau *diese* Identitaet, aber sinngemaess ;-/

das wird hier verletzt. Erschwert wird es allerdings dadurch, dass beim Aufnehmen von Funktionsadressen gesonderte Regeln zur Aufloesung von Ueberladungen gelten, bei denen tatsaechlich der links stehende Typ mit einbezogen wird - nur haben wir es hier weder mit einer ueberladenen Funktion zu tun, noch duerfte es ueberhaupt einen Unterschied machen weil der Typ links ja jeweils derselbe ist.

Somit wuerde ich zu eindeutig nicht standardkonformem Verhalten tendieren. Ob man das als Bug bezeichnen kann, ist eine andere Frage :-) Diese Syntax, um die Signatur einer Memberfunktion als Signatur einer ungebundenen Funktion abzuleiten, kannte ich uebrigens auch nicht - ich habe bislang immer die laengliche Idiotenvariante gewaehlt *hust*, die da lautet: die einzelnen Komponenten der Signatur (Rueckgabetyp, Parameter) einzeln als Templatetypen deduzieren lassen und dann manuell per typedef wieder zusammenfriemeln. Erfordert pro Parameteranzahl ein Template, netterweise.

[Schrompf]

Danke nochmal - ich habe hier schon wieder unerträglich viel gelernt.

Somit wuerde ich zu eindeutig nicht standardkonformem Verhalten tendieren. Ob man das als Bug bezeichnen kann, ist eine andere Frage :-) Diese Syntax, um die Signatur einer Memberfunktion als Signatur einer ungebundenen Funktion abzuleiten, kannte ich uebrigens auch nicht - ich habe bislang immer die laengliche Idiotenvariante gewaehlt *hust*, die da lautet: die einzelnen Komponenten der Signatur (Rueckgabetyp, Parameter) einzeln als Templatetypen deduzieren lassen und dann manuell per typedef wieder zusammenfriemeln. Erfordert pro Parameteranzahl ein Template, netterweise.

Ja, das ist auch der Weg, den ich jetzt gewählt habe. Ich muss mir nur noch *hust* den Source nach Hause schicken *hust* und umschreiben, dann kann ich ihn auch gern mal hochladen.