Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ich bin dafür leider vollkommen ungeeignet, da ich keine Ahnung von C++ habe. Ich setze das QP-C (ohne ++) framework schon einige Jahre im embedded-Bereich ein und bin davon sehr begeistert. Für die meisten Aufgaben ziehe ich QP jederzeit einem RTOS vor. Ob es auch für den eibd die richtige Wahl ist kann ich nicht beurteilen, der Umstieg auf ein event/actor/return-to-completion (RTC) Modell würde eventuell dazu führen, dass einiges umgebaut werden muss.
Ich kenne pthsem nicht, aber
"Pth (...) provides non-preemptive priority-based scheduling for multiple threads of execution"
könnte ein Hinweis darauf, sein, dass der Weg nicht soweit ist.
"pthsem is an extend version, with support for semaphores added."
Der in knxd verwendete C++-Anteil ist relativ überschaubar (keine Templates, kein Operator Overloading, etc.).
Die Semaphoren in pthsem werden eigentlich nur verwendet, um zu signalisieren, dass eine Queue nicht leer ist – was man wiederum nur deswegen braucht, weil der einzelne Aktor auf mehrere Events lauschen "muss" (meistens: eine Queue, ein Objekt dass der Task beendet werden soll, und einen Timeout o.Ä.) und die Queue-Abstraktion in pth(sem) keine Eventquelle ist. Das kann man um Einiges zielführender programmieren, d.h. jeder Aktor bekommt genau eine Queue und höchstens einen Timeout – und wenn man mehr braucht, will man eigentlich mehr als einen Aktor. :-P
QP-C sieht so aus, als könnte es genau dieses Modell perfekt unterstützen.
DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben
Wenn eibd sowieso schon Aktoren nutzt, drängt es sich natürlich auf auch ein Aktor-framework einzusetzen. Es gibt übrigens auch QP-C++ (und einige andere Aktor Implementierungen für C++ die ich aber nicht kenne)
Ich habe mir mal den QP-C++-Code angesehen. Sagen wir mal so: Idiomatisches C++ sieht ein bisschen anders aus. :-/
Zu ihrer Ehrenrettung muss man dazusagen, dass QP aus dem Embedded-Bereich kommt und sich "idiomatisches C++" und "optimierter Code für embedded-Systeme" gegenseitig so'n bisschen ausschließen. Aber diese Erkenntnis hilft bei knxd nur bedingt was.
DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben
Könntest du mal ein konkretes Beispiel nennen? Ich bin mir sicher, dass Herr Samek gute Gründe hatte das Framework genau so zu implementieren wie es ist.
Ich kenne nur die C Version und der Code ist mit der beste den ich jeh gesehen habe.
Wie ist deine Meinung zum eibd-code? Gefällt dir der besser?
Konkretes Beispiel: Objekte mit statischen Funktionen und "me" als erstem Parameter, statt normale Methoden mit implizitem "this".
Zeiger auf Methoden sind syntaktisch ein bisschen nervig, aber wirklich kein Hexenwerk.
Ich sehe mir das demnächst mal genauer an (und frage ggf. nach), aber erst wenn Sourceforge wieder funktioniert.
DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben
Ich vermute, dass der Grund dafür ist, die C und C++ Version möglichst ähnlich zu halten. Mit dem expliziten "me" und structs die als ersten member die struct der Basisklasse enthalten wird in QP-C die Objektorientierung implementiert.
Auch diesen Code verstehe ich nicht wirklich, schließlich tut
Code:
Baseclass_foo(&c->super, ...)
genau dasselbe -- ist aber wenigstens an dieser Stelle typsicher. Mit C++ bekomme ich die umgekehrte Richtung mit einem <dynamic_cast> gebacken – aber wenn man den Code so schreibt, dann geht dieser Vorteil verloren.
Egal. Kann man alles beheben und/oder damit leben.
Es gibt halt zwei fundamental verschiedene Alternativen an dieser Stelle – entweder ein Framework wie QP-C, das auf C-Kompatibilität setzt, oder man verwendet gleich die nativen Features von C++11 (bzw. Boost:. Letzteres hätte den Vorteil, dass sich Leute, die C++ bereits können, nicht erst einarbeiten müssen.
DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben
Es ist sicher nicht sinnvoll irgendwelche Änderungen an QP durchzuführen. Samek wird seine Gründe haben, dass QP-C++ so aussieht wie es aussieht und im Forum auf sourceforge (ist wieder da übrigens) gibt er schnell sehr kompetent Antwort. Er wird sicher interressiert sein zu hören, dass QP als framework für den eibd in Betracht gezogen wird.
Ich habe mich nochmal umgeschaut und es gibt ja inzwischen einiges an Aktor-frameworks für C++ da sollte doch was dabei sein wenn QP nicht das richtige ist.
Danke, aber den direkten Download kenne ich schon, sonst hätte ich nicht den "me"-Parameter anmeckern können …
nur: zum Verständnis von Code ist dieVersionsgeschichte für mich sehr hilfreich. Ich fühle mich gehandicapt wenn ich die nicht habe und nachsehen kann, wie und wieso Code entstanden ist, den ich nicht auf Anhieb verstehe.
DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben
Soweit ich weiß existiert das git-repo erst ein paar Monate, du wirst da wahrscheinlich nicht viel sehen.
Da sind die umfangreichen release-notes bestimmt hilfreicher.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar