From 2fd3629d80a23e9e3e4419f53677ce3277e7e6b5 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 16 Jul 2024 23:34:38 +0200 Subject: [PATCH] Invocation: difficulties with defining a suitable `DataBuilder` MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As a direct consequence of the insights regarding Dependency-Injection, a ''Builder Toolkit'' is required, which can be used to adapt various kinds of ''Weaving Patterns'' — since obviously it is not possible to settle down on a single Pattern, and thus several ''families of builders'' will emerge, one for each ''line of construction'' for ''Weaving Patterns''. To stress this point, what I am coding here is a prototype, aimed at being used as part of a **Test Domain Ontology** — and other Domain Ontologies (e.g. für FFmpeg) will certainly require other construction schemes for their Weaving Patterns. So this is an open field, and can not be settled once and for all. This immediately leads to another, rather technical problem: If we're about to work with ''delegate Builders,'' then also a way to pass-down the allocator configuration is required. We had settled on a preliminary solution with the helper `DataBuilder`, yet this solution looks like it defines how `lib::SeveralBuilder` should be used in most of the cases. So there is now a conflict between the existing definition scheme for `lib::SeveralBuilder`, which was achieved in a bottom-up way, and a slightly different definition scheme ''as it should be'' Starting to attack this latter detail problem, as a first step, the definition of `DataBuilder` can be simplified by collapsing it with the `lib::allo::SetupSeveral` --- src/steam/engine/node-builder.hpp | 20 ++--- wiki/thinkPad.ichthyo.mm | 136 ++++++++++++++++++++---------- 2 files changed, 96 insertions(+), 60 deletions(-) diff --git a/src/steam/engine/node-builder.hpp b/src/steam/engine/node-builder.hpp index 43dbd367b..5f8cc322e 100644 --- a/src/steam/engine/node-builder.hpp +++ b/src/steam/engine/node-builder.hpp @@ -112,27 +112,17 @@ namespace engine { template class ALO =std::void_t, typename...INIT> struct AlloPolicySelector { - template - static auto - setupBuilder (INIT&& ...alloInit) - { - return lib::makeSeveral() - .template withAllocator (forward (alloInit)...); - } + using Setup = lib::allo::SetupSeveral; + + template + using PolicyForAllo = typename Setup::template Policy; template - using BuilderType = decltype(setupBuilder (std::declval()...)); + using BuilderType = lib::SeveralBuilder>; }; struct UseHeapAlloc { - template - static auto - setupBuilder() - { - return lib::makeSeveral(); - } - template using BuilderType = lib::SeveralBuilder; }; diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 104772f74..31a8d8cc5 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -2604,9 +2604,7 @@ - - - +

wenn Log-Anzeige verworfen wird @@ -2656,9 +2654,7 @@ - - - +

Erläuterung: DockItem ist ein 1-elementiger GTK-Container, @@ -2725,9 +2721,7 @@ - - - +

das ist das Fazit meiner Untersuchung. @@ -2772,9 +2766,7 @@ - - - +

entweder sie laufen über den Getter, @@ -3266,9 +3258,7 @@ - - - +

...denn wir verwenden das Lumiera-Exception-API gar nicht @@ -3963,9 +3953,7 @@ - - - +

zieht komplett-Umbau @@ -5372,9 +5360,7 @@ - - - +

»professionell« bedeutet: unaufdringlich und klar @@ -6839,9 +6825,7 @@ - - - +

...um die Entwicklung des Designs zu erzwingen @@ -8567,9 +8551,7 @@ - - - +

alles mit einer Form des IterExplorer machbar ist @@ -10658,9 +10640,7 @@ - - - +

weil der Aufruf von join(&&) selber wasserdicht ist @@ -13747,9 +13727,7 @@ - - - +

...statt die gesamte Matching-Engine mit einer Art @@ -52925,9 +52903,7 @@ - - - +

grundlegender Widerspruch @@ -86692,8 +86668,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
ein Zwischending: BufferDescriptor

- - + @@ -86714,8 +86689,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + @@ -86728,8 +86702,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
...im Gegensatz zum Baumuster des Node-Graphen, der stets abwärts gerichtet ist: eine Node kennt nur ihre Vorläufer, aber der BufferDescriptor verweist aufwärts auf einen globalen Service

- - + @@ -87725,6 +87698,74 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + + + + + + + + + + + + + + +

+ Alle Typen sind bekannt und bereits angeschrieben; die neulich gefundene Lösung mit dem decltype(<builder>)-Trick hat mich zwar zum Ziel gebracht, ist aber unnötig indirekt — man könnte durchaus die Typen ineinander einsetzen und dann in eine einzige Typedef reduzieren +

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

+ Namens-Idee: AlloPolicySelector +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -88242,11 +88283,17 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + + + + + + @@ -88358,8 +88405,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
...denn wir verweisen darauf per Referenz oder Pointer

- - +