diff --git a/research/try.cpp b/research/try.cpp index cb65ff34b..535ba99f4 100644 --- a/research/try.cpp +++ b/research/try.cpp @@ -60,6 +60,51 @@ typedef unsigned int uint; cout << "Probe " << STRINGIFY(_XX_) << " ? = " << _XX_ < +class DependencyFactory + { + public: + static void + build (SRV*& instance) + { + UNIMPLEMENTED ("how to access the per-type factory"); + } + }; + + + +template +class DependInject; + +template +class Depend + { + static SRV* instance; + + friend class DependInject; + + public: + SRV& + operator() () + { + if (!instance) + { + ClassLock guard; + + if (!instance) + DependencyFactory::build (instance); + } + ENSURE (instance); + return *instance; + } + }; + +template +SRV* Depend::instance; + int main (int, char**) diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index f0a7052e5..7317223ce 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -26388,8 +26388,7 @@ lt. eigenen Benchmakrs deutlich schneller als rapidjson, welches eigentlich immer als der "schnelle" JSON-Parser gilt.

- - + @@ -26485,9 +26484,9 @@ - - + + @@ -26535,8 +26534,7 @@ - - + @@ -26565,8 +26563,7 @@ und benötigt diverse Laufzeit-Konsistenzchecks, die den Implementierungscode schwer lesbar machen

- - + @@ -26577,18 +26574,158 @@ - + - + + - - + + + + + + + + + + +

+ Bei diesem Wunsch-Profil bleibt nur eine Variante von Lösung-2 +

+ + + + + + + + +

+ ...denn nur eine dynamische Laufzeit-Factory ermöglicht, jederzeit  den Konstruktionsmodus zu wechseln +

+ + + + + + + + + + + +

+ ...denn nur ein Instanz-Pointer kann umgebogen oder auf NULL zurückgesetzt werden. +

+

+ Der einzige Ausweg aus diesem Dilemma wäre eine statische Lösung, +

+

+ in der bereits durch den #include von lib/depend.hpp endgültig klar wäre, +

+

+ was für eine Art von Dependency-Factory zum Einsatz kommen soll. Denn nur auf diesem +

+

+ Weg könnte der Optimiser unmittelbar auf eine Singleton-Instanz im statischen Speicher +

+

+ zugreifen, nach einem Check auf ein atomic<bool>. +

+

+ +

+

+ Eine solche statische Lösung allerdings widerspricht nicht nur meinen Wünschen, +

+

+ sondern wäre auch architektonisch ungünstig, denn dadurch +

+
    +
  • + entsteht eine zentrale DI-Konfiguration +
    • +
  • + erfolgt eine Rückverkopplung von lib/depend.hpp auf die Applikations-Struktur +
    • +
+ + + + + + + + + + +

+ ...denn er muß komplett generisch sein, und lib/depend.hpp darf keinerlei Kenntnis +

+

+ über die konkrete DependencyFactory voraussetzen. Denn sonst würden wir die +

+

+ Freiheit der dynamischen Laufzeit-Konfiguration verlieren. +

+ + + + + + + + + + +

+ ...denn ein Lambda kann in dieser Lage grundsätzlich keinen optimierungs-Vorteil bringen, +

+

+ und die konventionelle Lösung hat demgegenüber den Vorteil, daß sie Struktur und Kontrakt explizit macht. +

+ + + + + + + + + + +

+ ...denn es läuft darauf hinaus, daß die Nutzung eines Dienstes zwar on demand erfolgt, +

+

+ jedoch stets erst nach seiner Bereitstellung. So etwas läßt sich niemals über einzelne +

+

+ technische Einrichtungen lösen, denn es ist eine Frage des Aufbaues der gesamten Applikation. +

+

+ Es gibt hierfür nur zwei Lösungswege +

+
    +
  • + dynamisch: man definiert alle Abhängigkeiten durch Regeln und zieht das System nach Bedarf konsistent hoch, was bedingt, daß alle Abhängigkeiten über diesen Mechanismus laufen müssen +
    • +
  • + statisch: man strukturiert das System so, daß Nutzer erst nach dem Hochfahren der von ihnen benötigten Subsysteme aktiv sein können +
    • +
+ + + + + + @@ -26605,12 +26742,71 @@ + + + + + + +

+ scheidet für unser Nutzungsmuster aus +

+ + + + + + + + +

+ ...denn es bedutet effektiv, daß viele Instanz-Zeiger "herumfliegen", +

+

+ welche man in einer zentralen Registry erfassen müßte, um sie bei Bedarf +

+

+ wieder auf NULL zurücksetzen zu können. +

+ + + - + + + + + + + + + + + + + + + + + + + + + - + + + + + + + + + + + @@ -27817,8 +28013,7 @@ oder neu in das Window-System gemappt wird.

- - +