ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Invocation: continue draft of a simple 1:1 WeavingPattern

Browse source 
...which brings about various (preliminary) decisions regarding
Metadata storage in the `Turnout`-object, which acts as a guidance
and specification for the actual invocation for this specific node.

As starting point, I choose the ''KISS'' solution of embedding some
blocks of `UninitialisedStorage` directly into the `Turnout`; obviously
these blocks must be oversized, since we can not effort emitting a
dedicated template instance for each different count of input / output
feeds. Moreover, these data buffers are assumed to be filled with
valid objects by the builder ''(this is a lurking danger)''
This commit is contained in:
Fischlurch 2024-07-10 02:35:29 +02:00
parent 0b938320ea
commit ec65e2b7b9
4 changed files with 260 additions and 32 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
src/steam/engine/feed-manifold.hpp
View file

@ -73,6 +73,15 @@ namespace engine {
BuffS inBuff;
BuffS outBuff;
uint resultSlot{0};
BuffHandle
result() const
{
ENSURE (resultSlot < N, "invalid result buffer retrieved.");
return outBuff[resultSlot];
}
};

2
src/steam/engine/proc-node.hpp
View file

@ -79,6 +79,8 @@ namespace engine {
virtual BuffHandle weave (TurnoutSystem&) =0;
};
using PortRef = std::reference_wrapper<Port>;
/**
* Interface: Description of the input and output ports,
* processing function and predecessor nodes for a given ProcNode.

55
src/steam/engine/turnout.hpp
View file

@ -267,6 +267,61 @@ namespace engine {
};
template<class PAR, uint N>
struct SimpleWeavingPattern
: PAR
{
using Feed = FeedManifold<N>;
uint fanIn{0};
uint fanOut{0};
template<class X>
using Storage = lib::UninitialisedStorage<X,N>;
Storage<PortRef> leadPort;
Storage<BufferDescriptor> inDescr;
Storage<BufferDescriptor> outDescr;
//////////////////////////////////////////OOO builder must set-up those descriptors
Feed
mount()
{
return Feed{};
}
void
pull (Feed& feed, TurnoutSystem& turnoutSys)
{
for (uint i=0; i<fanIn; ++i)
{
BuffHandle inputData = leadPort[i].weave (turnoutSys);
feed.inBuff.createAt(i, move(inputData));
}
}
void
shed (Feed&)
{
/* NOP */
}
void
weft (Feed&)
{
/* NOP */
}
void
fix (Feed&)
{
/* NOP */
}
};
/**
* Processing structure to activate a Render Node and produce result data.
* @tparam PAT a _Weaving Pattern,_ which defines in detail how data is retrieved,

226
wiki/thinkPad.ichthyo.mm
View file

@ -757,9 +757,7 @@
</node>
<node CREATED="1484876010871" ID="ID_175784507" MODIFIED="1576282358159" TEXT="Design-Problem: restliches Tangible-Protokoll">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
wirkt alles mehr oder weniger beliebig...
@ -790,9 +788,7 @@
</node>
<node CREATED="1484799551220" ID="ID_496503271" MODIFIED="1576282358158" TEXT="Fehlermeldung + Segfault">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
0000000937: ERR: core-service.hpp:111: worker_3: ~CoreService: Some UI components are still connected to the backbone.
@ -812,9 +808,7 @@
</node>
<node CREATED="1484800480472" ID="ID_1441013524" MODIFIED="1576282358158" TEXT="Sanity-Check in CoreService anpassen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...mu&#223; diejenigen Bus-Verbindungen abziehen, die von Members dieser Klasse stammen
@ -2028,9 +2022,7 @@
<node CREATED="1535637534163" ID="ID_1194572504" MODIFIED="1535637548308" TEXT="kann mit &quot;Reveal&quot;-Funktion kombiniert werden"/>
<node CREATED="1535638307459" ID="ID_1697210606" MODIFIED="1535638391524" TEXT="possibly to discover dynamically">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...wenn wir eine Mix-in -Implementierung w&#228;hlen
@ -3509,9 +3501,7 @@
</node>
<node CREATED="1538281741419" FOLDED="true" ID="ID_1964821489" MODIFIED="1561827464647">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
ein <b>ZombieCheck</b>&#160;spricht an
@ -6005,9 +5995,7 @@
<node CREATED="1567875314411" ID="ID_26242186" MODIFIED="1567875341444" TEXT="erreichbar im Wizard | Men&#xfc; &quot;help&quot; &gt; &quot;self tests...&quot;"/>
<node CREATED="1567875342584" ID="ID_18019089" MODIFIED="1576282358139" TEXT="hat ein Notebook mit diversen Tabs...">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...welche ad hoc mit beil&#228;ufig geschriebenem Debug/Test-Code belegt werden
@ -9382,9 +9370,7 @@
<icon BUILTIN="button_ok"/>
<node CREATED="1511919050960" ID="ID_1621131204" MODIFIED="1512256810082" TEXT="grunds&#xe4;tzliches Problem jedes Iterator-Dekorators">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
wir haben bisher viel zu naiv angenommen,
@ -86982,6 +86968,11 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</html></richcontent>
<icon BUILTIN="clanbomber"/>
</node>
<node COLOR="#5b280f" CREATED="1720572510904" ID="ID_353816206" MODIFIED="1720572647135" TEXT="trotzdem klassifiziere ich das vorerst als &#xbb;zuk&#xfc;nftiger Sonderfall&#xab;">
<arrowlink COLOR="#894a3d" DESTINATION="ID_1659889610" ENDARROW="Default" ENDINCLINATION="531;-27;" ID="Arrow_ID_1852537899" STARTARROW="None" STARTINCLINATION="675;29;"/>
<icon BUILTIN="yes"/>
<icon BUILTIN="hourglass"/>
</node>
</node>
<node CREATED="1719790776594" ID="ID_544743149" MODIFIED="1719790788364" TEXT="brauche also einen Funktor / lazyVal hier"/>
</node>
@ -87176,8 +87167,8 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1719877434824" ID="ID_1694561227" MODIFIED="1719877456732" TEXT="ungekl&#xe4;rt: Output-Select / Mehrfach-Output">
<icon BUILTIN="flag-pink"/>
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#5f0140" CREATED="1719877434824" ID="ID_1694561227" MODIFIED="1720565192028" TEXT="Kl&#xe4;rung: Output-Select / Mehrfach-Output">
<icon BUILTIN="yes"/>
<node CREATED="1719877460036" ID="ID_70397480" MODIFIED="1719877516064" TEXT="der Output aus einen Port ist das N-te Resultat">
<node CREATED="1719877521676" ID="ID_1152039385" MODIFIED="1719877629486" TEXT="wie ist das N-te Resulat sichtbar?">
<richcontent TYPE="NOTE"><html>
@ -87236,7 +87227,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_cancel"/>
</node>
</node>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1719961008465" ID="ID_813357391" MODIFIED="1719961027714" TEXT="Problem hier : Spec und Implementierung mischen sich">
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1719961008465" ID="ID_813357391" MODIFIED="1720565201527" TEXT="Problem hier : Spec und Implementierung mischen sich">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1719961035792" ID="ID_1537523544" MODIFIED="1719961054626" TEXT="N-tes Resultat wird einmal als &#xbb;Port&#xab; gedacht"/>
<node CREATED="1719961055974" ID="ID_1173813263" MODIFIED="1719961064552" TEXT="dann wieder als &#xbb;Slot&#xab;"/>
@ -87246,7 +87237,15 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="idea"/>
</node>
</node>
<node CREATED="1719961121933" ID="ID_1186198930" MODIFIED="1719961277949" TEXT="Beschlu&#xdf;: nicht Mehrfach-Outputs, sondern Array-wertige Outputs">
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1719961121933" ID="ID_1186198930" MODIFIED="1720565233208">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
<u>Beschlu&#223;</u>: nicht Mehrfach-Outputs, sondern <b>Array-wertige Outputs</b>
</p>
</body>
</html></richcontent>
<linktarget COLOR="#67434d" DESTINATION="ID_1186198930" ENDARROW="Default" ENDINCLINATION="-3;-54;" ID="Arrow_ID_43760137" SOURCE="ID_1979667669" STARTARROW="None" STARTINCLINATION="-125;4;"/>
<icon BUILTIN="yes"/>
<node CREATED="1719962133644" ID="ID_227187176" MODIFIED="1719967032585">
@ -87302,8 +87301,9 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1719878960113" ID="ID_577817518" MODIFIED="1719878987431" TEXT="diese mu&#xdf; im jeweiligen Turnout materialisiert sein">
<icon BUILTIN="info"/>
</node>
<node CREATED="1719878992490" ID="ID_33806321" MODIFIED="1719879054037" TEXT="f&#xfc;r jede Buffer-Position: eine Konstruktor-Spec">
<node CREATED="1719878992490" ID="ID_33806321" MODIFIED="1720567366517" TEXT="f&#xfc;r jede Buffer-Position: eine Konstruktor-Spec">
<arrowlink COLOR="#7c6bbe" DESTINATION="ID_286027863" ENDARROW="Default" ENDINCLINATION="-143;53;" ID="Arrow_ID_1638343077" STARTARROW="None" STARTINCLINATION="-483;30;"/>
<linktarget COLOR="#6555a4" DESTINATION="ID_33806321" ENDARROW="Default" ENDINCLINATION="-432;713;" ID="Arrow_ID_1589842372" SOURCE="ID_933061351" STARTARROW="None" STARTINCLINATION="-186;-18;"/>
<node CREATED="1719882207478" ID="ID_12570621" MODIFIED="1719882220334" TEXT="impliziert auch: Anzahl der Buffer-Positionen">
<icon BUILTIN="idea"/>
</node>
@ -87327,7 +87327,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</body>
</html></richcontent>
</node>
<node CREATED="1719879199315" ID="ID_872496577" MODIFIED="1719879608413" TEXT="man kann ihn in den ohnehin notwendigen lazyVal-Funktor mit hineinnehmen">
<node CREATED="1719879199315" ID="ID_872496577" LINK="#ID_157690220" MODIFIED="1719879608413" TEXT="man kann ihn in den ohnehin notwendigen lazyVal-Funktor mit hineinnehmen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
@ -87362,6 +87362,32 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1719882888638" ID="ID_1258833485" MODIFIED="1719882949314" TEXT="das Routing-Array ist komplett statisch darstellbar">
<linktarget COLOR="#3f7ec9" DESTINATION="ID_1258833485" ENDARROW="Default" ENDINCLINATION="-167;9;" ID="Arrow_ID_239864309" SOURCE="ID_1533275051" STARTARROW="None" STARTINCLINATION="-134;206;"/>
<icon BUILTIN="idea"/>
<node CREATED="1720573426377" ID="ID_1952656284" MODIFIED="1720573440660" TEXT="man k&#xf6;nnte es sogar explizit auf die Vor&#xe4;nger-Ports linken">
<icon BUILTIN="idea"/>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1720573462100" ID="ID_1034286938" MODIFIED="1720573551256" TEXT="noch nicht klar ob das wirklich komplett so durchf&#xfc;hrbar ist">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
dazu m&#252;&#223;te man erst mal diverse komplexe F&#228;lle im Detail durchspielen...
</p>
<ul>
<li>
ist es wirklich m&#246;glich, diese Aufl&#246;sung und Zuordnung sofort vom Builder-Call aus zu machen?
</li>
<li>
braucht man die tats&#228;chlichen Koordinaten wirklich nicht mehr sp&#228;ter, zur Laufzeit?
</li>
</ul>
</body>
</html></richcontent>
<icon BUILTIN="hourglass"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720573441927" ID="ID_878431324" MODIFIED="1720573603383" TEXT="versuche diesen Implementierungs-Ansatz">
<arrowlink COLOR="#db4778" DESTINATION="ID_1900172091" ENDARROW="Default" ENDINCLINATION="-567;-19;" ID="Arrow_ID_1645995790" STARTARROW="None" STARTINCLINATION="-1009;66;"/>
<icon BUILTIN="yes"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1719883006771" ID="ID_162502109" MODIFIED="1719883136999" TEXT="zus&#xe4;tzlich vermutlich ein Anteil, der zum &#xbb;WeavingPattern&#xab; geh&#xf6;rt">
<icon BUILTIN="flag-yellow"/>
@ -87706,14 +87732,124 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="flag-yellow"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720546461284" ID="ID_704402784" MODIFIED="1720546479593" TEXT="Skizze ins Unreine : eine Invocation">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720546405862" ID="ID_1380185144" MODIFIED="1720546513736" TEXT="Grundstruktur f&#xfc;r FeedManifold anlegen">
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1720546461284" ID="ID_704402784" MODIFIED="1720567304893" TEXT="Skizze ins Unreine : eine Invocation">
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1720546405862" ID="ID_1380185144" MODIFIED="1720567309445" TEXT="Grundstruktur f&#xfc;r FeedManifold anlegen">
<arrowlink COLOR="#3563bc" DESTINATION="ID_723925333" ENDARROW="Default" ENDINCLINATION="-1;162;" ID="Arrow_ID_1608020834" STARTARROW="None" STARTINCLINATION="627;40;"/>
<icon BUILTIN="pencil"/>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1720546521352" ID="ID_1680202759" MODIFIED="1720567301713" TEXT="ein einfaches WeavingPattern f&#xfc;r einen 1:1 Aufruf">
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1720567224202" ID="ID_933061351" MODIFIED="1720567366517" TEXT="Buffer-Konstruktor-Spec bereitstellen">
<arrowlink COLOR="#6555a4" DESTINATION="ID_33806321" ENDARROW="Default" ENDINCLINATION="-432;713;" ID="Arrow_ID_1589842372" STARTARROW="None" STARTINCLINATION="-186;-18;"/>
<icon BUILTIN="pencil"/>
<node CREATED="1720567428212" ID="ID_492216775" MODIFIED="1720567474487" TEXT="&#xe4;hnlich und im Zusammenhang mit dem Routing-Array">
<icon BUILTIN="idea"/>
</node>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1720567519640" ID="ID_519445088" MODIFIED="1720567528168" TEXT="Problem: Storage-Layout">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1720567557003" ID="ID_908654776" MODIFIED="1720567570269" TEXT="ganz analog zum Problem f&#xfc;r die FeedManifold"/>
<node CREATED="1720567572241" ID="ID_1323500221" MODIFIED="1720567587579" TEXT="nur da&#xdf; ich hier weitere Optionen f&#xfc;r die Allokation habe">
<icon BUILTIN="idea"/>
<node CREATED="1720567593278" ID="ID_1917701948" MODIFIED="1720569488158" TEXT="kann es inline in das Turnout legen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
das w&#228;re KISS; man w&#252;rde den gleichen Template-Parameter N heranziehen, der auch die FeedManifold steuert; dieser wird nach dem Schema &#187;eins&#171;, &#187;zwei&#171;, &#187;viele&#171; belegt. Zus&#228;tzlich gibt es f&#252;r diesen Ansatz dann eine dynamische Spec &#252;ber die tats&#228;chliche Anzahl der Buffer In/Out (die stets &lt;= N w&#228;re)
</p>
</body>
</html>
</richcontent>
<linktarget COLOR="#504a80" DESTINATION="ID_1917701948" ENDARROW="Default" ENDINCLINATION="-196;10;" ID="Arrow_ID_1275152336" SOURCE="ID_1379190851" STARTARROW="None" STARTINCLINATION="208;0;"/>
</node>
<node CREATED="1720567844916" ID="ID_1339827409" MODIFIED="1720568335686" TEXT="separat allozierten Buffer vernwenden">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Im einfachsten Fall w&#228;re das genauso wie die erste L&#246;sung, nur da&#223; der Buffer nicht im Haupt-Objekt liegt (aber nat&#252;rlich trotzdem im Allocation-Cluster). Allerdings g&#228;be es hier noch eine weitere, halb-dynamische L&#246;sung: man w&#252;rde explizit einen Buffer dynamisch allozieren (direkter Allokator-Aufruf, bei dem man die Anzahl Elemente angibt). Das l&#228;uft auf einen minimalistischen Spezial-Container hinaus, oder eine ScopedCollection mit Custom-Allocator, oder dann gleich die n&#228;chste L&#246;sung....
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1720567864650" ID="ID_382412515" MODIFIED="1720568417566" TEXT="STL-Container mit custom Alloc verwenden">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...dies ist mit wenig Entwicklungs-Aufgand umzusetzen, erfordert dann aber trotzdem eine explizite Verdrahtung des Allocators und damit eine Vermischung zwischen Objekt-Konstruktion und Builder/Allocator.
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1720567926106" ID="ID_1451628034" MODIFIED="1720568810548" TEXT="dynamische Descriptor-Liste definieren">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Unabh&#228;ngig davon, welche der drei vorgenannten L&#246;sungen zum Zuge kommt, gibt es steths noch eine weitere, komplexere Variante, die aber sehr attraktiv erscheint: es ist n&#228;mlich in den weitaus meisten F&#228;llen so, da&#223; nur ein einziger, einheitlicher Buffer-Typ zum Einsatz kommt; daher l&#228;uft das Belegen eines Array mit einem expliziten Deskriptor f&#252;r jeden &#187;Slot&#171; auf erhebliche Speicherverschwendung hinaus. Stattdessen k&#246;nnte man versucht sein, die Belegung durch ein St&#252;ck Code machen zu lassen (eine Closure), und daf&#252;r eine Meta-Spec zu interpretieren. Das wird aber in jedem Fell recht komplexer Code, der dann auch zur Render-Zeit l&#228;uft (ja wirklich, in jedem Aufruf), und deshalb wieder das Problem aufwirft, woher man die Storage f&#252;r tempor&#228;re Datenstrukturen nimmt. Denn solche wird es zwingend geben, schlie&#223;lich mu&#223; man ja irgendwie markieren, was die <i>bereits behandelten Spezialf&#228;lle</i>&#160;sind, und welche &#187;Slots&#171; damit &#252;brig bleiben und mit dem Standard-Fall behandelt werden m&#252;ssen. Ja mei!
</p>
</body>
</html>
</richcontent>
</node>
</node>
<node CREATED="1720569454461" ID="ID_1379190851" MODIFIED="1720569494189" TEXT="fange mit der KISS-L&#xf6;sung an">
<arrowlink COLOR="#504a80" DESTINATION="ID_1917701948" ENDARROW="Default" ENDINCLINATION="-196;10;" ID="Arrow_ID_1275152336" STARTARROW="None" STARTINCLINATION="208;0;"/>
<icon BUILTIN="yes"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1720574429481" HGAP="25" ID="ID_558040709" MODIFIED="1720574974389" VSHIFT="12">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
diese L&#246;sung ist wohl etwas<i>&#160;brachial</i>
</p>
</body>
</html>
</richcontent>
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...vor allem gibt es kein &#187;Sicherheitsnetz&#171; &#8212; ein Umstand, der mich nachdenklich stimmt, da hier doch ein sehr komplexes Code-System entsteht, in dem die Ausf&#252;hrungs-Pfade keineswegs auf sicheren, festen Bahnen verlaufen... <i>Sollte dann wohl doch in Betracht ziehen, einen passenden, speichersicheren &#187;in-Place&#171;-Container zu implementieren</i>
</p>
</body>
</html></richcontent>
<arrowlink COLOR="#e72c46" DESTINATION="ID_374254461" ENDARROW="Default" ENDINCLINATION="2123;-72;" ID="Arrow_ID_1323424774" STARTARROW="None" STARTINCLINATION="-2473;168;"/>
<icon BUILTIN="messagebox_warning"/>
</node>
</node>
</node>
<node COLOR="#5b280f" CREATED="1720572338140" ID="ID_1820151066" MODIFIED="1720572390628" TEXT="bin jetzt wieder im Zweifel wegen dem Konstruktor-&#x3bb;">
<icon BUILTIN="stop-sign"/>
<node CREATED="1720572392179" ID="ID_1659889610" MODIFIED="1720573034935" TEXT="sehe das als einen ehr hypithetischen Spezialfall">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...grunds&#228;tzlich besteht diese M&#246;glichkeit, und sie k&#246;nnte eine gewisse Relevanz bekommen, sobald wir es mit Hardware-Accelleration zu tun haben. Dennoch halte ich das nicht f&#252;r den Regelfall, und zudem treibt es die Komplexit&#228;t hoch
</p>
</body>
</html>
</richcontent>
<linktarget COLOR="#894a3d" DESTINATION="ID_1659889610" ENDARROW="Default" ENDINCLINATION="531;-27;" ID="Arrow_ID_1852537899" SOURCE="ID_353816206" STARTARROW="None" STARTINCLINATION="675;29;"/>
</node>
<node CREATED="1720572417472" ID="ID_1892978300" MODIFIED="1720572435945" TEXT="wenn das wirklich n&#xf6;tig wird (YAGNI)..."/>
<node CREATED="1720572436630" ID="ID_60200424" MODIFIED="1720572460182" TEXT="dann kann man immer noch ein spezielles Weaving-Pattern daf&#xfc;r aufbauen"/>
<node CREATED="1720572464914" ID="ID_1119846327" MODIFIED="1720572540180" TEXT="fange also nur mit einem BufferDescriptor-Array an">
<node CREATED="1720573045524" ID="ID_1644013527" MODIFIED="1720573072547" TEXT="BufferDescriptor sind beliebig duplizierbar"/>
<node CREATED="1720573073663" ID="ID_1122948575" MODIFIED="1720573088876" TEXT="es wird ein unique-Key erzeugt und in einer Map registriert"/>
<node CREATED="1720573089822" ID="ID_247390072" MODIFIED="1720573104936" TEXT="abgesehen davon sind es Value-Objekte ohne Identit&#xe4;t"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720573559675" ID="ID_1900172091" MODIFIED="1720573594815" TEXT="versuche mal ein direkt Objekt-gelinktes Routing-Array zu implementieren">
<linktarget COLOR="#db4778" DESTINATION="ID_1900172091" ENDARROW="Default" ENDINCLINATION="-567;-19;" ID="Arrow_ID_1645995790" SOURCE="ID_878431324" STARTARROW="None" STARTINCLINATION="-1009;66;"/>
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720546521352" ID="ID_1680202759" MODIFIED="1720546544475" TEXT="ein einfaches WeavingPattern f&#xfc;r einen 1:1 Aufruf">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
</node>
@ -88019,6 +88155,32 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<arrowlink COLOR="#aa0f59" DESTINATION="ID_1626724421" ENDARROW="Default" ENDINCLINATION="-981;30;" ID="Arrow_ID_1208476495" STARTARROW="None" STARTINCLINATION="661;38;"/>
<icon BUILTIN="help"/>
</node>
<node CREATED="1720574923303" ID="ID_284878377" MODIFIED="1720574930985" TEXT="Design und Code-Qualit&#xe4;t">
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1720574616950" ID="ID_374254461" MODIFIED="1720574974390" TEXT="die inPlace-Storage-L&#xf6;sung in Turnout ist gef&#xe4;hrlich">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...und zwar, weil sie nicht <i>speichersicher ist!</i>
</p>
<p>
Das ist genau die Sorte Code, die man zwar durchaus aus Performance-Gr&#252;nden schreiben kann, aber dann besser nur in einem sorgsam abgezirkelten Implementierungs-Zusammenhang. Genau diese Eingrenzung ist hier aber nicht gegeben: vielmehr entsteht hier ein Baukasten-System, und es ist ohne Weiteres m&#246;glich, da&#223; ein Turnout mit falschen Parametern initialisiert wird.
</p>
<p>
</p>
<p>
&#160; <font color="#b00101">&#9888; In einem solchen Fall k&#246;nnte die Ausf&#252;hrung direkt in die Interpretation </font>
</p>
<p>
<font color="#b00101">&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;von <b>uninitialisiertem Speicher</b>&#160;laufen.</font>
</p>
</body>
</html></richcontent>
<linktarget COLOR="#e72c46" DESTINATION="ID_374254461" ENDARROW="Default" ENDINCLINATION="2123;-72;" ID="Arrow_ID_1323424774" SOURCE="ID_558040709" STARTARROW="None" STARTINCLINATION="-2473;168;"/>
<icon BUILTIN="messagebox_warning"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1713824835597" ID="ID_1311484733" MODIFIED="1713825651947" TEXT="Dokumentation">
<icon BUILTIN="bell"/>