From 43373e11e7b178981aeb8d2a535a2717daa2015f Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Thu, 24 Oct 2024 23:51:45 +0200 Subject: [PATCH] Invocation: prepare mechanism for default input wiring MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The intention is to offer an automatic 1:1 association between the »input parameter slots« of the processing function and the ''lead nodes,'' thereby always using the same default port, corresponding to the current port number under construction. Unfortunately, the preceding refactoring removed the information necessary for a simple implementation, as the port array is now built up late, in the final build() function... --- src/steam/engine/node-builder.hpp | 22 +++ src/steam/engine/weaving-pattern-builder.hpp | 4 +- wiki/thinkPad.ichthyo.mm | 151 ++++++++++++++----- 3 files changed, 138 insertions(+), 39 deletions(-) diff --git a/src/steam/engine/node-builder.hpp b/src/steam/engine/node-builder.hpp index b1fb5d70a..f739198ea 100644 --- a/src/steam/engine/node-builder.hpp +++ b/src/steam/engine/node-builder.hpp @@ -278,6 +278,7 @@ namespace engine { using _Par = PortBuilderRoot; WAB weavingBuilder_; + uint defaultPort_; public: @@ -352,12 +353,33 @@ namespace engine { PortBuilder(_Par&& base, FUN&& fun) : _Par{move(base)} , weavingBuilder_{forward (fun), _Par::leads_.policyConnect()} + , defaultPort_{0} ////////////////////////////////////////////////////////////////OOO brauche separaten Zähler! wo? { } friend class PortBuilderRoot; }; + /** + * @param fun invocation of the actual _data processing operation._ + * @remarks + * - a _»weaving pattern«_ is applied for the actual implementation, which amounts + * to a specific style how to route data input and output and how to actually integrate + * with the underlying media handling library, which exposes the processing functionality. + * - the standard case of this connectivity is to associate input and output connections + * directly with the »parameter slots« of the processing function; a function suitable + * for this pattern takes two arguments (input, output) — each of which is a std::array + * of buffer pointers, corresponding to the »parameter slots« + * - what is bound as \a FUN here thus typically is either an adapter function provided by + * the media-library plug-in, or it is a lambda directly invoking implementation functions + * of the underlying library, using a buffer type (size) suitable for this library and for + * the actual media frame data to be processed. + * - the `fun` is deliberately _taken by-value_ and then moved into a »prototype copy« within + * the generated `Turnout`, from which an actual copy is drawn anew for each node invocation. + * - notably this implies that the implementation code of a lambda will be _inlined_ into the + * actual invocation call, while possibly _creating a copy_ of value-captured closure data; + * this arrangement aims at exposing the actual invocation for the optimiser. + */ template template auto diff --git a/src/steam/engine/weaving-pattern-builder.hpp b/src/steam/engine/weaving-pattern-builder.hpp index e10f1bf15..8686c60c4 100644 --- a/src/steam/engine/weaving-pattern-builder.hpp +++ b/src/steam/engine/weaving-pattern-builder.hpp @@ -350,6 +350,7 @@ namespace engine { struct WeavingBuilder : util::MoveOnly { + using FunSpec = _ProcFun; using TurnoutWeaving = Turnout>; static constexpr SizMark sizMark{}; @@ -395,7 +396,6 @@ namespace engine { WeavingBuilder fillRemainingBufferTypes() { - using FunSpec = _ProcFun; auto constexpr FAN_O = FunSpec::FAN_O; using BuffO = typename FunSpec::BuffO; uint cnt = FAN_O - buffTypes.size(); @@ -426,7 +426,9 @@ namespace engine { typeConstructor (providers[i++])); ENSURE (leadPorts.size() <= N); + ENSURE (leadPorts.size() == FunSpec::FAN_I); ENSURE (outTypes.size() <= N); + ENSURE (outTypes.size() == FunSpec::FAN_O); using PortDataBuilder = DataBuilder; // provide a free-standing functor to build a suitable Port impl (≙Turnout) diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 2ad191fa3..bdae6d649 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -9308,9 +9308,7 @@ - - - +

...nur was billig ist, @@ -9744,9 +9742,7 @@ - - - +

an welcher Stelle wird diese Mechanik @@ -10754,9 +10750,7 @@ - - - +

man kann move(iter) verwenden, @@ -12294,9 +12288,7 @@ - - - +

neue Einsicht 31.12.17 @@ -14517,9 +14509,7 @@ - - - +

// generic lambda, operator() is a template with one parameter @@ -48885,9 +48875,7 @@ - - - +

Implementierung: Diff-Bindung -> Diff-System @@ -49575,9 +49563,7 @@ - - - +

GTK macht das auch in der Tat genau so @@ -50062,9 +50048,7 @@ - - - +

beendet Deregistrierung, @@ -50342,9 +50326,7 @@ - - - +

gelöst in GCC-5 -- backport unwahrscheinlich @@ -50504,9 +50486,7 @@ - - - +

nach work site @@ -88398,7 +88378,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + + @@ -88411,12 +88392,24 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + +

+ ...denn es sind noch die flexiblen Strategy-Templates darüber gelegt, und außerdem hatte ich den eigentlichen Allocator nur als protected-Mix-in eingebettet — und deshalb wird der für einen normalen (generierten) copy-Konstruktor nicht in sichtbar; kopiert würde ja auf dem gesamten (zusammengesetzten) Strategy-Template, und das hängt nominell durchaus vom Element-Typ ab, der aber in diesem Fall, beim Weitergeben einer Initialisierung, durchaus variabel sein kann (nur der Basis-Allokator ist stets kompatibel) +

+ + + + + - - - - + + + + @@ -88424,10 +88417,39 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
denn das Standard-C++-Front-end für Allocation-Cluster ist ein std::allocator<byte>, und deshalb sind alle Varianten untereinander kompatibel (und das einzige verbleibende Problem wäre, daß der Allokator eine protected-Basisklasse ist)

- - + + + + + + + +

+ damit man von einem existierenden SeveralBuilder ausgehend weiter verdrahten kann +

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

+ Konzeptionell ist das Strategy-Template offen angelegt, aber in der tatsächlichen Implementierung dürfte seine Rolle inzwischen weitgehend festgelegt sein. Und in diesem aktuellen Gebrauch spielt der Element-Typ nur eine Rolle zur Ansteuerung des Allocators, und auch die Konstruktor-Argumente werden komplett von oben bis auf die Basis-Ebene durchgereicht. Da zudem der Basis-Allocator an den C++-Standard angelehnt ist, kann man unterstellen, daß sich praktisch immer ein passender Alocator für einen anderen als den gegebenen Element-Typ konstruieren läßt. +

+ + + + + + @@ -89439,7 +89461,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + + @@ -89518,6 +89542,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

+ @@ -90386,6 +90411,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + @@ -90468,6 +90494,55 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + + + + +

+ weil nur der PortBuilder seine eigene Position erschließen kann (weil er auf den geerbten DataBuilder zugreifen kann) +

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

+ d.h. der Default würde mit hochgezählt, kann aber per Setter auf andere Werte gesetzt werden +

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