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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+