SimpleSig - minimalistic signal/slots lib for C++

[Master674b]

Originally Posted by Tasiro

Es ist also für eine Programmiersprache? Das ist dann ein anderes Thema. Ich kenne Lua nicht, wenn es aber schwach typisiert ist und eine automatische Speicherverwaltung sein Eigen nennt, müsste doch eigentlich irgendwo eine Referenz "hängen bleiben" und somit verhindern, dass deine Rückruf-Funktionen verworfen wird. Du müsstest dann doch nur noch testen, ob es wirklich Funktionen ist. Damit ist Rückrufen Genüge getan. Zumindest, wenn Lua die Verbindungen nicht selbst verwalten darf... Aber auch dann unterstützt deine Signal-Bibliothek das momentan nicht hinreichend, dass etwas kaputtgehen könnte - weder durch Lua, noch durch irgendjemanden sonst.
Angenommen, deine Verbindungen haben keinen intelligenten Zeiger oder eine sonstige Sicherungsmethode. Solange du mit deinen Signalen umgehst, wird das aber auch nur dann gefährlich, wenn du Lua die Kontrolle über Verbindungsobjekte übergibst. Diese sollten schließlich nur in dem Kontext eines Signals vorkommen und nicht darüber hinaus am Leben gelassen werden.

Das mache ich gerne, es würde mich freuen, geholfen zu haben.

Das war der 31.10., oder?

Für mein Script API muss ich halt sicher gehen, dass die Scriptautoren nichts böses machen können, da darf die Anwendung auch nicht crashen, wenn er das Verbindungsobjekt behält und damit arbeitet, aber das Signal schon zerstört wurde. Mit meinem momentanen Aufbau ist das ja kein Problem.

Ich warte einfach drauf bis MS mal Dreamspark aktualisiert. Da ist noch kein RTM drin. Der Launch von VS13 ist glaub ich irgendwann im November, aber RTM = Release...

boost::signals2 ist momentan nichtmal lauffähig unter VS2013, da es noch nen Compiler Bug gibt. Der MS Compiler bevorzugt nämlich variadische Template Überladungen vor einfachen Templates.

[Tasiro]

Originally Posted by Master674b

Für mein Script API muss ich halt sicher gehen, dass die Scriptautoren nichts böses machen können, da darf die Anwendung auch nicht crashen, wenn er das Verbindungsobjekt behält und damit arbeitet, aber das Signal schon zerstört wurde. Mit meinem momentanen Aufbau ist das ja kein Problem.

Du erlaubst also die manuelle Verwaltung von Verbindungen? Interessant. Warum?
Du brauchst std::weak_ptr nur, wenn du zulässt, dass Verbindungen Signale überleben - und die zugrundeliegenden Funktionsobjekte auch. Viel einfacher ist das mit Referenzen.
Was man alles falsch machen kann:

ConnectionRef f () {
	return Signal ().connect (struct {
		void operator () () {}
	} ());
}

Würdest du so programmieren? Würdest du Lua die Macht geben, das zu tun?

Originally Posted by Master674b

boost::signals2 ist momentan nichtmal lauffähig unter VS2013, da es noch nen Compiler Bug gibt. Der MS Compiler bevorzugt nämlich variadische Template Überladungen vor einfachen Templates.

Ah, noch ein Fehler?

[Master674b]

Originally Posted by Tasiro

Du erlaubst also die manuelle Verwaltung von Verbindungen? Interessant. Warum?
Du brauchst std::weak_ptr nur, wenn du zulässt, dass Verbindungen Signale überleben - und die zugrundeliegenden Funktionsobjekte auch. Viel einfacher ist das mit Referenzen.
Was man alles falsch machen kann:

ConnectionRef f () {
	return Signal ().connect (struct {
		void operator () () {}
	} ());
}

Würdest du so programmieren? Würdest du Lua die Macht geben, das zu tun?

Ah, noch ein Fehler?

Ne, aber der Scriptautor kann ein Signal erstellen (z.B. wenn er ein C++ Objekt erzeugt, dass ein Signal beinhaltet), daraus ein Verbindungsobjekt bekommen über connect und dann das Objekt, dass das Signal hält löschen aber das Verbindungsobjekt weiterverwenden. Zum Beispiel die connected() Funktion.

Jo gibt noch mehrere Fehler momentan :C
Das Problem ist, boost darf wieder Hacks einfügen, bis MS das gebacken bekommt. Wird wohl so drauf hinauslaufen.

[Tasiro]

Originally Posted by Master674b

Ne, aber der Scriptautor kann ein Signal erstellen (z.B. wenn er ein C++ Objekt erzeugt, dass ein Signal beinhaltet), daraus ein Verbindungsobjekt bekommen über connect und dann das Objekt, dass das Signal hält löschen aber das Verbindungsobjekt weiterverwenden. Zum Beispiel die connected() Funktion.

Du musst das Verbindungsobjekt ja nicht ebenfalls an Lua zurückgeben. Für gewöhnlich werden Rückruffunktionen dadurch wieder entfernt, dass diese erneut übergeben werden, nur dieses Mal einer anderen Funktion. Oder du sagst, dass das undefiniertes Verhalten ist, undefiniertes Verhalten gibt es sicher auch mit Lua allein. Willst du dich gegen Murphy absichern, oder gegen Machiavelli?

Originally Posted by Master674b

Jo gibt noch mehrere Fehler momentan :C
Das Problem ist, boost darf wieder Hacks einfügen, bis MS das gebacken bekommt. Wird wohl so drauf hinauslaufen.

Die ändern das dafür auch in schön großen Paketen - alle paar Monate einmal.