ecst

ecst

Experimentelle und Arbeit in der Progress C ++ 14 Multithread-Kompilierzeit-Entitätskomponenten-System-Header-nur-Bibliothek.

Überblick

Eine erfolgreiche Entwicklung komplexer Echtzeitanwendungen und Spiele erfordert ein flexibles und effizientes Unternehmensmanagementsystem. Wenn ein Projekt komplizierter wird, ist es wichtig, eine elegante Möglichkeit zu finden, Objekte zu komponieren, um die Wiederholung der Code zu verhindern, die Modularität zu verbessern und leistungsstarke Optimierungsmöglichkeiten zu öffnen.

Das Architekturmuster des Entitätskomponenten-Systems wurde entwickelt, um die oben genannten Vorteile zu erzielen, indem Daten von der Logik getrennt wurden.

• Entitäten können aus kleinen, wiederverwendbaren und generischen Komponenten bestehen.

• Komponenten können in zusammenhängenden Speicherbereichen gespeichert werden, wodurch die Datenlokalität und Cache-Freundlichkeit verbessert werden.

• Die Anwendungslogik kann leicht parallelisiert und abstrahiert werden von den Objekten selbst und ihrer Speicherrichtlinien.

• Der Zustand der Anwendung kann mit weniger Aufwand serialisiert und über das Netzwerk geteilt werden.

• Eine modularere, generische und leicht testbare Codebasis.

"Ecst" wurde als mein BCS -Abschlussprojekt entwickelt.

---

Erste Schritte

• Anweisungen erstellen

• Code Beispiel

• Lizenz

---

Weitere Informationen

• Begleitende These

• Folien

  • HINWEIS: Diese sind mit einer früheren Version der Bibliothek zusammen mit C ++ 2016 vorgestellt

---

Terminologie

• Entitäten: definiert von Adam Martin (siehe These) als „grundlegende konzeptionelle Bausteine“ eines Systems, das konkrete Anwendungs-Objekte darstellt. Sie haben keine anwendungsspezifischen Daten oder Logik.

• Komponenten: Kleine, wiederverwendbare Typen, die Entitäten bestehen. Noch einmal unter Berufung auf Adam Martin in (siehe These) , bezeichnet ein Komponententyp „eine Entität als Besitz eines bestimmten Aspekts“. Komponenten speichern Daten, enthalten jedoch keine Logik.

• Systeme: Anbieter der Implementierungslogik für Entitäten, die einen bestimmten Satz von Komponententypen besitzen.

• Äußere Parallelität: Begriff in ECST verwendet, das das Konzept des Ausführens mehrerer Systeme definiert, die parallel nicht voneinander abhängen. Die Implementierungsdetails werden in Kapitel 10 analysiert (siehe These) . Konzeptionell wird ein implizit gerichtetes acyclisches Diagramm dank der Kenntnis der Systemabhängigkeiten zur Kompilierungszeit erstellt. Die Ausführung der impliziten DAG wird von einem Systemplaner -Typ behandelt, der während der Definition der Einstellungen angegeben ist.

• Innere Parallelität: Andere, die parallel separate Systeme ausführen, unterstützt die Aufteilung eines einzelnen Systems in mehrere Unteraufgaben, die auf separaten Threads ausgeführt werden können. Viele Systeme, wie diejenigen, die funktional reine Kompetenzen darstellen, enthalten keine Nebenwirkungen, die ihren eigenen Zustand ändern oder Wechselwirkungen zwischen den abonnierten Entitäten definieren: Dies sind Hauptbeispiele für „peinlich parallele“ Berechnungen.

---

FAQ

• "Wo finde ich Dokumentation für die API?"

  • Siehe Ausgabe Nr. 10.

• "Können wir Komponenten haben, die nicht standardmäßig konstruktiv sind?"

  • Dies ist in der Vergangenheit schon einmal aufgetaucht. Die Antwort lautet Nein - siehe Ausgabe 8.

• "Ich versuche zu/schreiben zu/von meiner Komponente, aber ich erhalte einen Kompilierungsfehler. Was passiert? "

  • Systeme müssen bei Compiles-Time wissen, auf welche Komponententypen sie zugreifen und wie (schreibgeschützte oder Schreibzugriff) . Dies muss bei der Definition von Systemsignaturen angegeben werden. Weitere Informationen finden Sie in Ausgabe 4.

• "Ist es möglich, über die an Entitäten verbundenen Komponenten zu iterieren, ohne sich in der Prozessfunktion eines Systems zu befinden?"

  • Siehe Ausgabe 9.

• "Wie steuern Sie, ob mein System parallel oder als einzelner Thread ausgeführt wird? "

  • Die kontextweite innere Parallelität muss aktiviert werden, indem Sie duld_inner_parallelism () aufrufen, damit Systeme in mehreren Unterbereitungen aufgeteilt werden können. Innere Parallelitätsstrategien können während der Definition der Systemsignatur bei der Kompilierung für bestimmte Systeme angepasst und komponiert werden.

• "Was ist der Unterschied zwischen einem einzel-betrügerischen System und dem Deaktivieren des inneren Paralellismus?"

  • Das Deaktivieren der inneren Parallelität verhindert, dass alle Systeme unabhängig von ihrer inneren Parallelitätsstrategie in mehreren Unterbereitungen aufgeteilt werden. Wenn ein System Single-Threaded in mehreren Unterbereitungen aufgeteilt wird, kann dies nur für Systeme erforderlich sein, die Datenstrukturen aufrechterhalten oder auf der Iterierung aller Entitäten im selben Thread angewiesen sind.