Invocation: reconsider data access and allocator usage from Builder
The next step is to round out the first prototypical implementation, which requires access to ''lead node ports'' and thereby generally places focus on the interplay of ''data builders'' within the ongoing build process. While the prototype still uses the fall-back to simple heap allocation, notably the intended usage will require to wire-through the connection to a single `AllocationCluster`. This poses some challenge, since further ''data builders'' will be added step-wise, implying that this wiring can not be completed at construction time. Thus it seems indicated to slightly open-up the internal allocator policy base template used by `lib::SeveralBuilder` to allow for some kind of ''cross building'' based on a shared compatible base allocator type, so that the allocation policy wiring can be passed-on from an existing `SeveralBuilder`
This commit is contained in:
parent
554a64e212
commit
0144049f9d
5 changed files with 158 additions and 86 deletions
|
|
@ -210,6 +210,15 @@ namespace lib {
|
|||
: Allo{std::move (allo)}
|
||||
{ }
|
||||
|
||||
/** allow cross-initialisation when using same kind of base allocator */
|
||||
template<typename X>
|
||||
ElementFactory (ElementFactory<X,ALO>& relatedFac)
|
||||
: ElementFactory{relatedFac.baseAllocator()}
|
||||
{ }
|
||||
|
||||
template<typename O, template<typename> class XALO>
|
||||
friend class ElementFactory;
|
||||
|
||||
|
||||
Bucket*
|
||||
create (size_t cnt, size_t spread, size_t alignment =alignof(I))
|
||||
|
|
@ -403,12 +412,15 @@ namespace lib {
|
|||
SeveralBuilder() = default;
|
||||
|
||||
/** start Several build using a custom allocator */
|
||||
template<typename...ARGS, typename = meta::enable_if<std::is_constructible<Policy,ARGS...>>>
|
||||
template<typename...ARGS, typename = meta::enable_if<std::is_constructible<Policy,ARGS&&...>>>
|
||||
SeveralBuilder (ARGS&& ...alloInit)
|
||||
: Several<I>{}
|
||||
, Policy{forward<ARGS> (alloInit)...}
|
||||
{ }
|
||||
|
||||
/** expose policy to configure other ServeralBuilder */
|
||||
Policy& policyConnect() { return *this; }
|
||||
|
||||
|
||||
|
||||
/* ===== Builder API ===== */
|
||||
|
|
|
|||
|
|
@ -33,6 +33,7 @@
|
|||
** some goal oriented building blocks, that can be combined and directed with greater
|
||||
** clarity by the control structure to govern the build process.
|
||||
**
|
||||
**
|
||||
** # Levels of connectivity building
|
||||
**
|
||||
** The actual node connectivity is established by a process of gradual refinement,
|
||||
|
|
@ -40,7 +41,7 @@
|
|||
** builder and descriptor records to collect information, which is then emitted by a
|
||||
** _terminal invocation_ to produce the result; the higher levels thereby rely on the
|
||||
** lower levels to fill in and elaborate the details.
|
||||
** - Level-1 is the preparation of an actual frame processing operation; the Level-1-builder
|
||||
** - *Level-1* is the preparation of an actual frame processing operation; the Level-1-builder
|
||||
** is in fact the implementation class sitting behind a Render Node's _Port._ It is called
|
||||
** a _Turnout_ and contains a preconfigured »blue print« for the data structure layout
|
||||
** used for the invocation; its purpose is to generate the actual data structure on the
|
||||
|
|
@ -48,12 +49,12 @@
|
|||
** library functions. Since the actual data processing is achieved by a _pull processing,_
|
||||
** originating at the top level exit nodes and propagating down towards the data sources,
|
||||
** all the data feeds at all levels gradually link together, forming a _TurnoutSystem._
|
||||
** - Level-2 generates the actual network of Render Nodes, which in turn will have the
|
||||
** Turnout instances for Level-1 embedded into its internal ports. Conceptually, a
|
||||
** - *Level-2* generates the actual network of Render Nodes, which in turn will have the
|
||||
** Turnout instances for Level-1 embedded into their internal ports. Conceptually, a
|
||||
** _Port_ is where data production can be requested, and the processing will then
|
||||
** retrieve its prerequisite data from the ports of the _Leads,_ which are the
|
||||
** prerequisite nodes situated one level below or one step closer to the source.
|
||||
** - Level-3 establishes the processing steps and data retrieval links between them;
|
||||
** - *Level-3* establishes the processing steps and data retrieval links between them;
|
||||
** at this level, thus the outline of possible processing pathways is established.
|
||||
** After spelling out the desired connectivity at a high level, the so called »Level-3 build
|
||||
** walk« is triggered by invoking the [terminal builder operation](\ref ProcBuilder::build()
|
||||
|
|
@ -66,17 +67,17 @@
|
|||
** Since the low-level-Model is a massive data structure comprising thousands of nodes, each with
|
||||
** specialised parametrisation for some media handling library, and a lot of cross-linking pointers,
|
||||
** it is important to care for efficient usage of memory with good locality. Furthermore, the higher
|
||||
** levels of the build process will generate additional temporary data structures, which is gradually
|
||||
** refined until the actual render node network can be emitted. Each builder level can thus be
|
||||
** outfitted with a custom allocator — typically an instance of lib::AllocationCluster. Notably
|
||||
** the higher levels can be attached to a separate AllocationCluster instance, which will be
|
||||
** discarded when the build process is complete, while Level-2 (and below) uses the allocator
|
||||
** for the actual target data structure, which will be retained and until a complete segment
|
||||
** of the timeline is superseded and has been re-built.
|
||||
** levels of the build process will generate additional temporary data structures, refined gradually
|
||||
** until the actual render node network can be emitted. Each builder level can thus be outfitted
|
||||
** with a custom allocator — typically an instance of lib::AllocationCluster. Notably the higher
|
||||
** levels can be attached to a separate AllocationCluster instance, which will be discarded once
|
||||
** the build process is complete, while Level-2 (and below) uses the allocator for the actual
|
||||
** target data structure, which has to be retained while the render graph is used; more
|
||||
** specifically until a complete segment of the timeline is superseded and has been re-built.
|
||||
** @remark syntactically, the custom allocator specification is given after opening a top-level
|
||||
** builder, by means of the builder function `.withAllocator<ALO> (args...)`
|
||||
**
|
||||
** @todo WIP-WIP-WIP 7/2024 Node-Invocation is reworked from ground up -- some parts can not be
|
||||
** @todo WIP-WIP-WIP 10/2024 Node-Invocation is reworked from ground up -- some parts can not be
|
||||
** spelled out completely yet, since we have to build this tightly interlocked system of
|
||||
** code moving bottom up, and then filling in further details later working top-down.
|
||||
**
|
||||
|
|
@ -129,7 +130,8 @@ namespace engine {
|
|||
template<class POL, class I, class E=I>
|
||||
using DataBuilder = lib::SeveralBuilder<I,E, POL::template Policy>;
|
||||
|
||||
|
||||
|
||||
|
||||
template<class POL, class DAT>
|
||||
class NodeBuilder;
|
||||
|
||||
|
|
@ -349,7 +351,7 @@ namespace engine {
|
|||
template<typename FUN>
|
||||
PortBuilder(_Par&& base, FUN&& fun)
|
||||
: _Par{move(base)}
|
||||
, weavingBuilder_{forward<FUN> (fun)}
|
||||
, weavingBuilder_{forward<FUN> (fun), _Par::leads_.policyConnect()}
|
||||
{ }
|
||||
|
||||
friend class PortBuilderRoot<POL,DAT>;
|
||||
|
|
|
|||
|
|
@ -130,7 +130,7 @@ namespace engine {
|
|||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
/* ==== strategy API for configuring the node operation ==== */
|
||||
|
||||
friend class ProcNode; /////////////////////////////////TODO 1/12 : wouldn't it be better to extract that API into a distinct strategy?
|
||||
friend class ProcNode; /////////////////////////////////OOO who needs friendship?
|
||||
|
||||
/** the wiring-dependent part of the node operation.
|
||||
* Includes the creation of a one-way state object on the stack
|
||||
|
|
@ -177,6 +177,12 @@ namespace engine {
|
|||
public:
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
Port&
|
||||
getPort (uint portIdx)
|
||||
{
|
||||
REQUIRE (portIdx <= wiring_.ports.size());
|
||||
return wiring_.ports[portIdx];
|
||||
}
|
||||
|
||||
/** Engine Core operation: render and pull output from this node.
|
||||
* On return, currentProcess will hold onto output buffer(s)
|
||||
|
|
|
|||
|
|
@ -39,12 +39,13 @@
|
|||
** inherits from an *Invocation Adapter* given as template parameter. So this constitutes
|
||||
** an *extension point* where other, more elaborate invocation schemes could be integrated.
|
||||
**
|
||||
**
|
||||
** # Interplay of NodeBuider, PortBuilder and WeavingBuilder
|
||||
**
|
||||
** The steam::engine::WeavingBuilder defined here serves as the low-level builder and adapter to
|
||||
** prepare the wiring and invocation. The builder-API allows to setup the wiring of input and
|
||||
** output-»slots« and control some detail aspects like caching. However, without defining any
|
||||
** connections explicitly, a simple 1:1 wiring scheme is employed
|
||||
** The steam::engine::WeavingBuilder defined here serves as the low-level builder and adapter
|
||||
** to prepare the wiring and invocation. The builder-API allows to setup the wiring of input
|
||||
** and output-»slots« and control some detail aspects like caching. However, without defining
|
||||
** any connections explicitly, a simple 1:1 wiring scheme is employed
|
||||
** - each _input slot_ of the function gets an input buffer, which is filled by _pulling_
|
||||
** (i.e. invoking) a predecessor node (a so called »lead«).
|
||||
** - for each _output slot_ a buffer is allocated for the processing function to drop off
|
||||
|
|
@ -52,8 +53,8 @@
|
|||
** - only one of these output buffers is used as actual result, while the other buffers
|
||||
** are just discarded (but may possibly be fed to the frame cache).
|
||||
**
|
||||
** Each [Processing Node](\ref ProcNode) represents one specific processing functionality on
|
||||
** a logical level; yet such a node may be able to generate several „flavours“ of this processing,
|
||||
** Each [Processing Node](\ref ProcNode) represents one specific processing functionality on a
|
||||
** logical level; yet such a node may be able to generate several „flavours“ of this processing,
|
||||
** which are represented as *ports* on this node. Actually, each such port stands for one specific
|
||||
** setup of a function invocation, with appropriate _wiring_ of input and output connections.
|
||||
** For example, an audio filtering function may be exposed on port-#1 for stereo sound, while
|
||||
|
|
@ -62,13 +63,13 @@
|
|||
** The WeavingBuilder is used to generate a single \ref Turnout object, which corresponds to
|
||||
** the invocation of a single port and thus one flavour of processing.
|
||||
**
|
||||
** On the architectural level above, the \ref NodeBuilder exposes the ability to set up a
|
||||
** At one architectural level above, the \ref NodeBuilder exposes the ability to set up a
|
||||
** ProcNode, complete with several ports and connected to possibly several predecessor nodes.
|
||||
** Using several NodeBuilder invocations, the _processing node graph_ can be built up starting
|
||||
** from the source (predecessors) and moving up to the _exit nodes,_ which produce the desired
|
||||
** calculation results. The NodeBuilder offers a function to define the predecessor nodes
|
||||
** (also designated as _lead nodes_), and it offers an entrance point to descend into a
|
||||
** PortBuilder, allowing to add the port definitions for this node step by step.
|
||||
** Using a sequence of NodeBuilder invocations, the _processing node graph_ can be built gradually,
|
||||
** starting from the source (predecessors) and moving up to the _exit nodes,_ which produce the
|
||||
** desired calculation results. The NodeBuilder offers a function to define the predecessor nodes
|
||||
** (also designated as _lead nodes_), and it offers an [entrance point](\ref NodeBuilder::preparePort)
|
||||
** to descend into a \ref PortBuilder, allowing to add the port definitions for this node step by step.
|
||||
**
|
||||
** On the implementation level, the PortBuilder inherits from the NodeBuilder and embeds a
|
||||
** WeavingBuilder instance. Moreover, the actual parametrisations of the NodeBuilder template
|
||||
|
|
@ -80,7 +81,7 @@
|
|||
** the low-level memory allocation and object creation functionality. The purpose of this
|
||||
** admittedly quite elaborate scheme is to generate a compact data structure, with high
|
||||
** cache locality and without wasting too much memory. Since the exact number of elements
|
||||
** and the size of those elements can be concluded only after the builder-API usage has
|
||||
** and the size of those elements can be deduced only after the builder-API usage has
|
||||
** been completed, the aforementioned functional datastructure is used to collect the
|
||||
** parametrisation information for all ports, while delaying the actual object creation.
|
||||
** With this technique, it is possible to generate all descriptors or entries of one
|
||||
|
|
@ -355,9 +356,9 @@ namespace engine {
|
|||
using TypeMarker = std::function<BuffDescr(BufferProvider&)>;
|
||||
using ProviderRef = std::reference_wrapper<BufferProvider>;
|
||||
|
||||
DataBuilder<POL, PortRef> leadPort;
|
||||
std::vector<TypeMarker> buffTypes;
|
||||
std::vector<ProviderRef> providers;
|
||||
DataBuilder<POL, PortRef> leadPorts;
|
||||
std::vector<TypeMarker> buffTypes;
|
||||
std::vector<ProviderRef> providers;
|
||||
|
||||
uint resultSlot{0};
|
||||
|
||||
|
|
@ -365,16 +366,18 @@ namespace engine {
|
|||
|
||||
FUN fun_;
|
||||
|
||||
WeavingBuilder(FUN&& init)
|
||||
: fun_{move(init)}
|
||||
template<typename...INIT>
|
||||
WeavingBuilder(FUN&& init, INIT&& ...alloInit)
|
||||
: leadPorts{forward<INIT> (alloInit)...}
|
||||
, fun_{move(init)}
|
||||
{ }
|
||||
|
||||
WeavingBuilder
|
||||
attachToLeadPort(ProcNode& lead, uint portNr)
|
||||
{
|
||||
PortRef portRef; /////////////////////////////////////OOO TODO need Accessor on ProcNode!!!!!
|
||||
leadPort.append (portRef);
|
||||
ENSURE (leadPort.size() <= N);
|
||||
PortRef portRef{lead.getPort (portNr)};
|
||||
leadPorts.append (portRef);
|
||||
ENSURE (leadPorts.size() <= N);
|
||||
return move(*this);
|
||||
}
|
||||
|
||||
|
|
@ -411,23 +414,23 @@ namespace engine {
|
|||
build()
|
||||
{
|
||||
// discard excess storage prior to allocating the output types sequence
|
||||
leadPort.shrinkFit();
|
||||
leadPorts.shrinkFit();
|
||||
|
||||
maybeFillDefaultProviders (buffTypes.size());
|
||||
REQUIRE (providers.size() == buffTypes.size());
|
||||
auto outTypes = DataBuilder<POL, BuffDescr>{}
|
||||
auto outTypes = DataBuilder<POL, BuffDescr>{leadPorts.policyConnect()}
|
||||
.reserve (buffTypes.size());
|
||||
uint i=0;
|
||||
for (auto& typeConstructor : buffTypes)
|
||||
outTypes.append (
|
||||
typeConstructor (providers[i++]));
|
||||
|
||||
ENSURE (leadPort.size() <= N);
|
||||
ENSURE (outTypes.size() <= N);
|
||||
ENSURE (leadPorts.size() <= N);
|
||||
ENSURE (outTypes.size() <= N);
|
||||
|
||||
using PortDataBuilder = DataBuilder<POL, Port>;
|
||||
// provide a free-standing functor to build a suitable Port impl (≙Turnout)
|
||||
return [leads = move(leadPort.build())
|
||||
return [leads = move(leadPorts.build())
|
||||
,types = move(outTypes.build())
|
||||
,procFun = move(fun_)
|
||||
,resultIdx = resultSlot
|
||||
|
|
|
|||
|
|
@ -8852,9 +8852,7 @@
|
|||
</node>
|
||||
<node CREATED="1511482495719" ID="ID_327135583" MODIFIED="1511482510962">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...und wenn die Scheitert, ist das ein <b>compile</b>-Fehler
|
||||
|
|
@ -9065,9 +9063,7 @@
|
|||
</node>
|
||||
<node CREATED="1512182366016" FOLDED="true" ID="ID_146727217" MODIFIED="1512926191761">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Aufrufpunkt: <b>invokeTransformation</b>()
|
||||
|
|
@ -9563,9 +9559,7 @@
|
|||
<node CREATED="1512440158486" ID="ID_1167307993" MODIFIED="1512440175103" TEXT="alle Layer, die darauf angewiesen sind...."/>
|
||||
<node CREATED="1512440175931" ID="ID_808598503" MODIFIED="1512440193040">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
implementieren ebenfalls <b>expandChildren</b>()
|
||||
|
|
@ -10979,9 +10973,7 @@
|
|||
</node>
|
||||
<node COLOR="#338800" CREATED="1513447822247" ID="ID_1725576262" MODIFIED="1513448159466" TEXT="jetzt scheint's zu funktionieren...">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
rLet(77943 < 18446744073709551615) → R
|
||||
|
|
@ -13033,9 +13025,7 @@
|
|||
</node>
|
||||
<node CREATED="1517018171153" ID="ID_912683774" MODIFIED="1518487921068" TEXT="wird ziemlich technisch in der Implementierung">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...denn Reolver ist ein UICoord::Builder und als Solcher non-copyable.
|
||||
|
|
@ -49085,9 +49075,7 @@
|
|||
<node CREATED="1502454064930" ID="ID_1876117833" MODIFIED="1502454072133" TEXT="brauche Entkoppelung"/>
|
||||
<node CREATED="1502454072649" ID="ID_1325287539" MODIFIED="1533608413997">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Abstraktion
|
||||
|
|
@ -49912,9 +49900,7 @@
|
|||
</node>
|
||||
<node CREATED="1448407054900" ID="ID_1277028437" MODIFIED="1557498707235">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
mark: Nachricht <i>downstream</i>
|
||||
|
|
@ -50173,9 +50159,7 @@
|
|||
</node>
|
||||
<node CREATED="1536441983485" ID="ID_330124350" MODIFIED="1576282358003" TEXT="Warnung: anonymous namespace">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...ist mir nicht völlig klar, warum das bei einigen Includes auftritt,
|
||||
|
|
@ -50487,9 +50471,7 @@
|
|||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1455290707481" ID="ID_551153117" MODIFIED="1518487921091">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
empfängt alle <b>state mark notificatons</b>
|
||||
|
|
@ -50569,9 +50551,7 @@
|
|||
<node CREATED="1488676134951" ID="ID_1426727929" MODIFIED="1518487921091" TEXT="N : M">
|
||||
<node CREATED="1488676119929" ID="ID_70646733" MODIFIED="1518487921091">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
einer könnte für
|
||||
|
|
@ -88172,9 +88152,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1721782887971" ID="ID_388496633" MODIFIED="1721783207223" TEXT="erfordert Umstellung des Builder-Mechanismus">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1721783212761" ID="ID_688164724" MODIFIED="1721783264389" TEXT="Vorsicht: Produkt (≙Turnout) wird sofort vom darüberliegenden Builder verarbeitet"/>
|
||||
<node CREATED="1721783265456" ID="ID_16528841" MODIFIED="1721783298976" TEXT="dieser schiebt das Produkt in das Several<Port>-Array">
|
||||
<node CREATED="1721783265456" ID="ID_16528841" MODIFIED="1729690120716" TEXT="dieser sammelt alle Turnouts im einem Several<Port>-Array">
|
||||
<icon BUILTIN="info"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1729690122843" ID="ID_1138966283" MODIFIED="1729690320736" TEXT="tatsächlich vewenden wir nun Funktor-Closures für ein direktes emplace<Turnout>(...)">
|
||||
<arrowlink COLOR="#5bb062" DESTINATION="ID_1761275309" ENDARROW="Default" ENDINCLINATION="-1537;-2205;" ID="Arrow_ID_256183749" STARTARROW="None" STARTINCLINATION="658;22;"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1721782897853" ID="ID_271206866" MODIFIED="1721785456553" TEXT="Konsequenz ⟹ fanIn und fanOut werden überflüssig"/>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1721833352848" ID="ID_1921234844" MODIFIED="1721844764395" TEXT="das verschobene Probem stellt sich wieder: Einbinden des Model-Context">
|
||||
|
|
@ -88398,19 +88382,75 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1729689486088" ID="ID_85442031" MODIFIED="1729689492347" TEXT="Allocator-Verdrahtung">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1729689495519" ID="ID_212333345" MODIFIED="1729689501090" TEXT="im NodeBuilder selber">
|
||||
<node COLOR="#435e98" CREATED="1729690350972" ID="ID_1661103424" MODIFIED="1729690426201" TEXT="Konfiguration besteht aus zwei Teilen">
|
||||
<icon BUILTIN="info"/>
|
||||
<node CREATED="1729690360283" ID="ID_814264432" MODIFIED="1729690364199" TEXT="eine Policy"/>
|
||||
<node CREATED="1729690365122" ID="ID_1833988387" MODIFIED="1729690370502" TEXT="INIT-Argumente"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1729690399022" ID="ID_1829703564" MODIFIED="1729690421337" TEXT="initiale Einrichtung durch quer-Builder-Ansatz">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1729690450367" ID="ID_399913981" MODIFIED="1729690493004" TEXT="Aufruf einer Builder-Funktion ⟼ neuer Builder-Typ mit adaptierter Policy">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node CREATED="1729690434609" ID="ID_471228411" MODIFIED="1729690449358" TEXT="schon beim lib::SeveralBuilder erfolgreich angewandt"/>
|
||||
<node CREATED="1729690497225" ID="ID_250896902" MODIFIED="1729690506851" TEXT="analog hier für den NodeBuilder übernommen"/>
|
||||
</node>
|
||||
<node CREATED="1729690511015" ID="ID_1345744881" MODIFIED="1729690525113" TEXT="brauche Möglichkeit zur Weitergabe per Verdrahtung">
|
||||
<node CREATED="1729690643848" ID="ID_1393862688" MODIFIED="1729690650184" TEXT="kann hier formal argumentieren">
|
||||
<node CREATED="1729690652137" ID="ID_707766560" MODIFIED="1729690668783" TEXT="der Policy-Typ muß zur Compilezeit weitergereicht werden"/>
|
||||
<node CREATED="1729690678125" ID="ID_94473929" MODIFIED="1729690847382" TEXT="alle Policies erben vom Allokator und sind somit kopierbar">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
die Policies und Adapter haben alle einen pass-through-ctor, welcher letztlich den ganz innen (protected) liegenden C++ -  Allokator initialisiert. Alles, was über diese Standard-C++-Mechanismen hinausgeht, muß über die Policy geregelt und eingebunden werden.  Relevantes Beispiel ist der AllocationCluster, für den in der Policy ein Zugangspunkt für dynamisches Justieren der aktuell letzten Allokation herausgeführt ist.
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1729693488842" ID="ID_771040034" MODIFIED="1729693495886" TEXT="ist aber etwas grenzwertig....">
|
||||
<node CREATED="1729693497185" ID="ID_1296261127" MODIFIED="1729693511053" TEXT="eigentlich brauche ich wieder so eine Art cross-Builder">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node CREATED="1729693529381" ID="ID_243390572" MODIFIED="1729693629731" TEXT="nur für Allocation-Cluster wäre Initialisierung mit dem eingebetteten Basis-Allokator möglich">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
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)
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1729693512727" ID="ID_119687582" MODIFIED="1729693527657" TEXT="denn die konkrete Policy ist auch an den Element-Typ gebunden"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1729689502130" ID="ID_1366722617" MODIFIED="1729689509145" TEXT="der PortBuilder erbt das damit"/>
|
||||
<node CREATED="1729689519188" ID="ID_1567678998" MODIFIED="1729690009528" TEXT="an den Weaving-Builder weitergeben">
|
||||
<arrowlink COLOR="#1f1a57" DESTINATION="ID_1326944262" ENDARROW="Default" ENDINCLINATION="-226;-782;" ID="Arrow_ID_973510776" STARTARROW="None" STARTINCLINATION="-147;11;"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1721002518189" ID="ID_539153824" MODIFIED="1721002527069" TEXT="Lead-Ports einfüllen">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1721002528188" ID="ID_1483660753" MODIFIED="1721002546307" TEXT="Ha! kann fanIn schrittweise hochzählen">
|
||||
<node COLOR="#5b280f" CREATED="1721002528188" ID="ID_1483660753" MODIFIED="1729689428544" TEXT="kann fanIn schrittweise hochzählen">
|
||||
<icon BUILTIN="idea"/>
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node COLOR="#435e98" CREATED="1729689431553" ID="ID_865437036" LINK="#ID_271206866" MODIFIED="1729689446334" TEXT="aus anderen Gründen überflüssig"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1721002548302" ID="ID_1439228362" MODIFIED="1721002561328" TEXT="brauche Port-Accessor auf ProcNode">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1721002564319" ID="ID_566779431" MODIFIED="1721002578582" TEXT="Connectivity herausführen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node COLOR="#338800" CREATED="1721002548302" ID="ID_1439228362" MODIFIED="1729689402403" TEXT="brauche Port-Accessor auf ProcNode">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1721002564319" ID="ID_566779431" MODIFIED="1729689360142" TEXT="direkter Zugriff intern auf Connectivity">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1721002570214" ID="ID_1634824320" MODIFIED="1721059868212" TEXT="verwendet lib::Several">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node COLOR="#338800" CREATED="1721002570214" ID="ID_1634824320" MODIFIED="1729689383572" TEXT="verwendet lib::Several ⟶ subscript-Operator">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -89341,6 +89381,15 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node CREATED="1728575095471" ID="ID_807507393" MODIFIED="1728580412842" TEXT="muß aber auch API-Design bedenken">
|
||||
<arrowlink COLOR="#507ec8" DESTINATION="ID_1267841334" ENDARROW="Default" ENDINCLINATION="-66;-100;" ID="Arrow_ID_537610685" STARTARROW="None" STARTINCLINATION="-257;20;"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1729689530770" ID="ID_1326944262" MODIFIED="1729690009528" TEXT="brauche Allocator für die DataBuilder">
|
||||
<linktarget COLOR="#1f1a57" DESTINATION="ID_1326944262" ENDARROW="Default" ENDINCLINATION="-226;-782;" ID="Arrow_ID_973510776" SOURCE="ID_1567678998" STARTARROW="None" STARTINCLINATION="-147;11;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1729689651901" ID="ID_1976833854" MODIFIED="1729689674827" TEXT="DataBuilder ≙ vorkonfigurierter SeveralBuilder"/>
|
||||
<node CREATED="1729689676009" ID="ID_405876288" MODIFIED="1729689689136" TEXT="kann mich an dem Schema aus dem NodeBuilder orientieren"/>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1729689734951" ID="ID_1618503875" MODIFIED="1729689762036" TEXT="Problem: Allocator-Init nach Konstruktor nicht mehr verfügbar">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1728856264065" ID="ID_647212329" MODIFIED="1728856511042" TEXT="erst im completePort() ggfs fall-back auf 1:1-Verdrahtung">
|
||||
<linktarget COLOR="#4225b0" DESTINATION="ID_647212329" ENDARROW="Default" ENDINCLINATION="-964;48;" ID="Arrow_ID_287970761" SOURCE="ID_1204792955" STARTARROW="None" STARTINCLINATION="-440;43;"/>
|
||||
<linktarget COLOR="#667ba9" DESTINATION="ID_647212329" ENDARROW="Default" ENDINCLINATION="73;-4;" ID="Arrow_ID_198065069" SOURCE="ID_1013813267" STARTARROW="None" STARTINCLINATION="-159;7;"/>
|
||||
|
|
@ -90103,7 +90152,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1729386797044" ID="ID_1761275309" MODIFIED="1729562612230" TEXT="Builder-Closure vom WeavingBuilder entkoppeln">
|
||||
<node COLOR="#338800" CREATED="1729386797044" ID="ID_1761275309" MODIFIED="1729690316126" TEXT="Builder-Closure vom WeavingBuilder entkoppeln">
|
||||
<linktarget COLOR="#5bb062" DESTINATION="ID_1761275309" ENDARROW="Default" ENDINCLINATION="-1537;-2205;" ID="Arrow_ID_256183749" SOURCE="ID_1138966283" STARTARROW="None" STARTINCLINATION="658;22;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1729386815675" ID="ID_1416710632" MODIFIED="1729561753982" TEXT="WeavingBuilder lebt nur temporär auf dem Stack">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
|
|
@ -90371,8 +90421,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
Denn std::decay macht genau das, was auch passiert, wenn man ein Argument<i>  by-value</i> nimmt. Und das ist hier auch aus anderen Gründen genau das, was wir brauchen: Egal ob Lambda oder Funktor order Funktions-Referenz, es wird erst mal im Builder materialisiert, und von dort weiter geschoben in die λ-closure, welche im Builder für den InvocationAdapter abgelegt ist; im Prototyp-Beispiel ist das die Klasse DirectFunctionInvocation. Das »Protokoll« für den Turnout und das SimpleWeavingPattern erwartet, daß in diesem Builder eine Fuktion oder ein Funktor buildFeed() gegeben ist. Das bedeutet, für jede Invocation wird eine <b>Kopie</b> der processing-Function gezogen und <b>direkt in den code des InvocationAdapters geinlined</b>. Typischerweise ist die processing-Function selber wiederum als Lamda definiert, und damit erfolgt ein sehr direkter und effizienter Aufruf der eigentlichen Library-Funktion
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="ksmiletris"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -90411,8 +90460,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
diese setzen den jeweiligen Turnout direkt per <b><font face="Monospaced">emplace()</font></b> in die Ziel-Storage
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#3b5a65" DESTINATION="ID_1973963222" ENDARROW="Default" ENDINCLINATION="1150;-31;" ID="Arrow_ID_1910798539" SOURCE="ID_1001603416" STARTARROW="None" STARTINCLINATION="931;37;"/>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -90571,7 +90619,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<linktarget COLOR="#dd0239" DESTINATION="ID_865228634" ENDARROW="Default" ENDINCLINATION="1738;0;" ID="Arrow_ID_1284493211" SOURCE="ID_474371188" STARTARROW="None" STARTINCLINATION="-299;23;"/>
|
||||
<icon BUILTIN="broken-line"/>
|
||||
</node>
|
||||
<node CREATED="1728861734053" ID="ID_1720499002" MODIFIED="1728861867336" TEXT="müßte das Produkt des WeavingBuilders konfigurierbar machen">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728861734053" ID="ID_1720499002" MODIFIED="1729689297880" TEXT="müßte das Produkt des WeavingBuilders konfigurierbar machen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -90580,6 +90628,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
|
|||
Loading…
Reference in a new issue