SimpleSig - minimalistic signal/slots lib for C++

Quote:

Originally Posted by Tasiro Warum so kompliziert void etc. ausschalten? Es reicht, ProxyRet<void> zu spezialisieren und ProxyRet<const void> etc. davon ableiten zu lassen. std::move ist in utility definiert. std::enable_if in type_traits. Compare (InputIterator first, InputIterator last): Die Benennung last ist irreführend. last wird niemals dereferenziert. Minimum und Maximum sind einfacher mit std::min_element und std::max_element zu implementieren, Signal::size mit std::count_if. ProxyRet <R> operator () (const Args &... args) const: Was ist mit "perfect forwarding"? Warum muss ich die "custom-compare Funktionen" in eine Klasse packen, Compare nennen und zu Templatefunktionen machen? Warum nicht das Konzept der Funktionsobjekte wie in der Standardbibliothek unterstützen? _generic_invoke(const FuncT& function): Wie wäre es mit remove_if? Es müsste so gehen, ich habe es nicht getestet: Code: template <typename FuncT> void _generic_invoke (const FuncT & function) const { Detail::CallLock g (m_callLock); m_connections.remove_if ([& function] (const std::shared_ptr <Detail::ConnectionBase <signature_t>> & connection) { if (! connection->connected ()) return true; function (connection->connectedSlot); return false; }); } mutable und const heißen beide "ist thread-sicher", oder sollten es. Auch ein konstantes Objekt (oder const T&) braucht ein veränderliches Objekt der Klasse std::mutex.

Quote:

mutable und const heißen beide "ist thread-sicher", oder sollten es. Auch ein konstantes Objekt (oder const T&) braucht ein veränderliches Objekt der Klasse std::mutex.

Quote:

Originally Posted by Master674b 6. kA wie meinst du denn? mit ner Predicate Funktion als invoke Argument?

Quote:

Originally Posted by MrSm!th Nochmal zu std::function, weil ich mir eigentlich sicher war, dass std::function zu dem Zweck existiert, der Arbeit mit Lambdas, Functors und normalen Funktionspointern eine gemeinsame Schnittstelle anzubieten. Also müsste doch ein Parameter vom Typ std::function auch alle 3 fassen können, oder habe ich da etwas falsch verstanden?

Quote:

Originally Posted by Tasiro Es wäre schön, wenn ich ein Lambda nutzen könnte. static Compare ist nicht so schön wie operator () (iter begin, iter end) const. std::function akzeptiert so ziemlich alles als Argument, nur ist es i. Allg. langsamer. Hier nicht, da der Typ der Slots nicht bekannt ist.

CompareF::operator()<T>(...);

Quote:

Originally Posted by Master674b Ist aber ein Problem, wenn es ein Template ist, dann müsstest du den so aufrufen: Code: CompareF::operator()<T>(...); das ist dann nicht mehr so schön. Da müsste dann der Funktor als template definiert werden.

std::cout << Signal <int (int, int, int)> ({slot1, slot2}).invoke ({1, 2, 3}, [] (std::initializer_list <int> results) {
    return std::max_element (results.begin (), results.end ());
}):

Quote:

Originally Posted by Tasiro Ich sehe gerade - es sind std::unique_ptr, std::shared_ptr und std::weak_ptr dabei, fehlt nur noch std::auto_ptr. Könntest du mir bitte erklären, wozu du std::shared_ptr brauchst (und nicht std::unique_ptr und T*, oder std::shared_ptr<const T>)? Es wäre schön, ein Beispiel dafür zu haben. Es fehlt vielleicht noch der ein oder andere Kommentar hier und da, etwa bei ProxyRet<const void>.

Quote:

Originally Posted by Master674b Connection Objekte können geshared werden.

int f () { return 1; }
int g () { return 2; }

int main () {
	SimpleSig::Signal <int ()> signal1;
	auto connection1 (signal1.connect (f));
	auto connection2 (signal1.connect (g));
	std::cout << * signal1.invoke <SimpleSig::Maximum> () << '\n';
	auto signal2 (signal1);
	std::cout << * signal1.invoke <SimpleSig::Maximum> () << " - " << * signal2.invoke <SimpleSig::Maximum> () << '\n';
	connection2.disconnect ();
	std::cout << * signal1.invoke <SimpleSig::Maximum> () << " - " << * signal2.invoke <SimpleSig::Maximum> () << '\n';
	std::cin.get ();
}

//Ausgabe:
// 2
// 2 - 2
// 1 - 1

Quote:

Originally Posted by Tasiro Wie? Durch Kopieren des Signals? Wenn ich dann eine Kopie erstelle und danach die vorher dem Orginal hinzugefügte Verbindung trenne, wird doch aber auch in der (vielleicht genau deswegen erstellten) Kopie das Signal getrennt... Soll das so? Beispiel: Code: int f () { return 1; } int g () { return 2; } int main () { SimpleSig::Signal <int ()> signal1; auto connection1 (signal1.connect (f)); auto connection2 (signal1.connect (g)); std::cout << * signal1.invoke <SimpleSig::Maximum> () << '\n'; auto signal2 (signal1); std::cout << * signal1.invoke <SimpleSig::Maximum> () << " - " << * signal2.invoke <SimpleSig::Maximum> () << '\n'; connection2.disconnect (); std::cout << * signal1.invoke <SimpleSig::Maximum> () << " - " << * signal2.invoke <SimpleSig::Maximum> () << '\n'; std::cin.get (); } //Ausgabe: // 2 // 2 - 2 // 1 - 1

Quote:

Originally Posted by Master674b Jo das soll so sein. Findest du das negativ? Du kannst die Connection-Objekte selbst ja auch kopieren bzw. davon ne ScopedConnection erstellen, die muss dann ja zwangsweise auch auf das selbe ConnectionBase Objekt zeigen.

Quote:

Originally Posted by Tasiro Das ist kontraintuitiv. Wenn ich etwas kopiere, dann nehme ich an, dass die Kopie prinzipiell unabhängig ist und eine nachfolgende Änderung an Elementen des Orginals die Kopie nicht beeinflusst. Du kannst zwar intern intelligente Zeiger nutzen, soviel du willst, das sollte sich aber nicht auf das erwartete Verhalten auswirken. Eine Verbindung hat für mich nur ein Signal, nicht unbegrenzt viele. Wenn ich also eine Verbindung trenne, wirkt sich das nicht auf alle möglichen Kopien aus. Dann könnte aber die Verbindung eine Referenz auf das besitzende Signal haben und sich selbst aus dem Signal austragen, intelligente Zeiger wären dann dafür auch nicht mehr notwendig. Wenn du dann bei einer verketteten Liste bleibst, sollten die Verbindungen vielleicht noch einen Iterator besitzen, der auf sie selbst (bzw. direkt davor) in der Liste zeigt. Wenn es eine einfach verkettete Liste ist, muss eine sich trennende/schließende Verbindung außerdem den Iterator der nächsten Verbindung aktualisieren. Wenn du keine Reihenfolge für die Aufrufe garantierst, könntest du auch std::vector nutzen und bei einer in der Mitte getrennten/geschlossenen Verbindung diese durch das letzte Element der Liste ersetzen.

Quote:

Originally Posted by Master674b Eigentlich wäre der smart pointer dann immer noch notwendig. Ein Signal könnte ja schon zerstört sein.

Quote:

Originally Posted by Master674b Um das zu beheben bräuchten die beiden gegenseitig Referenzen aufeinander, das klingt nach nem Designfehler für mich.

Quote:

Originally Posted by Tasiro Den Gültigkeitsbereich nicht beachten kann ich auch so. Davon abgesehen sollten Verbindungen nicht kopierbar sein und nur als Referenzen, Zeiger oder in Wrapper-Objekten verfügbar sein; was passierte denn, wenn ich eine bestehende Verbindung kopierte? Dann solltest du nicht anbieten, dass Verbindungen sich selbstständig trennen können. Wenn es effizient sein soll, wird das vom Nutzer verwendete Objekt so oder so einen Zeiger auf oder in das Signal haben, auch wenn das dann nicht das vom Signal verwaltete Objekt sein muss. Du könntest etwa (nur ein Beispiel) in dem Signal eine Liste von std::function<T> haben und bei Bedarf ein Verbindungsobjekt erstellen (connection_ref<T>), welches zum einen auf das std::function<T>-Objekt und zum anderen auf das Signal zeigt. Damit hast zu zyklische Zeiger erfolgreich vermieden, kannst aber dafür keine Referenz mehr zurückgeben und musst das Objekt jedes Mal neu erstellen. Außerdem können dann Verbindungen ohne besitzendes Signal nicht existieren. (Wer will der Erste sein, der darlegt, unter welchen Umständen das vielleicht doch möglich wäre?)

Quote:

Originally Posted by Master674b Ich guck mir nachher mal an wie andere Signal libs das regeln. Jedenfalls brauch ich diese Sicherheit hier. Bei mir im Projekt ist das ein LuaSignal, d.h. die Klasse brauche ich, um Lua-Callbacks zu realisieren, und die sollen natürlich so sicher wie nur irgend wie möglich sein. Auch wenn im Script der Gültigkeitsbereich der Verbindungen missachtet wird, darf nichts schief gehen.

Quote:

Originally Posted by Master674b Danke dir übrigens für die Mühen und Vorschläge =)

Quote:

Originally Posted by Master674b Sobald ich meine VS 2013 Lizenz hab guck ich mal ob ich das ganze eventuell noch etwas anpasse oder mehr Optionen bereitstelle.