Invocation: investigate Problems with allocation-growing
This investigation was set off by a warning regarding an unused argument in `SeveralBuilder`, using `AllocationPolicy::moveElem()` This warning is correct and easy to fix, but (luckily) it brought my attention to the fact that a `SeveralBuilder<Port>` can not grow dynamically, which is somewhat mitigated by the default policy to pre-allocate several elements, which would work to some degree but waste a lot of memory. This points to a deeper problem with the implementation pattern used for all those Builders: they create their product by-value, which must then be moved into the intended target location. And doing so is **extremely dangerous**, given that our very goal is to build a complex data structure internally connected by direct references and ideally also allocated with a high degree of memory locality. Unfortunately I do not see any favourable alternative yet; Ideally all products should be `NonCopyable` — but then, the builder implementation scheme would become even more complicated and less intuitive and additionally the client code would need to pre-declare the number of expected Leads and Ports (not clear if this is even feasible)
This commit is contained in:
parent
4a963c9fee
commit
634df743f0
4 changed files with 321 additions and 38 deletions
|
|
@ -343,6 +343,7 @@ namespace lib {
|
|||
}
|
||||
else
|
||||
{
|
||||
(void)src; (void)tar;
|
||||
NOTREACHED("realloc immovable type (neither trivially nor typed movable)");
|
||||
// this alternative code section is very important, because it allows
|
||||
// to instantiate this code even for »noncopyable« types, assuming that
|
||||
|
|
|
|||
|
|
@ -43,6 +43,7 @@
|
|||
#define STEAM_ENGINE_PROC_NODE_H
|
||||
|
||||
#include "lib/error.hpp"
|
||||
#include "lib/nocopy.hpp"
|
||||
#include "steam/common.hpp"
|
||||
#include "steam/asset/proc.hpp"
|
||||
#include "steam/mobject/parameter.hpp"
|
||||
|
|
@ -74,11 +75,16 @@ namespace engine {
|
|||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
class Port
|
||||
: util::MoveOnly //////////////////////////////////////////////////OOO not clear if necessary here, and requires us to declare the ctors!!! See Turnout
|
||||
{
|
||||
public:
|
||||
virtual ~Port(); ///< this is an interface
|
||||
|
||||
|
||||
virtual BuffHandle weave (TurnoutSystem&, OptionalBuff =std::nullopt) =0;
|
||||
|
||||
// compiler does not generate a move-ctor automatically due to explicit dtor
|
||||
Port() = default;
|
||||
Port(Port&&) = default;
|
||||
};
|
||||
|
||||
using PortRef = std::reference_wrapper<Port>;
|
||||
|
|
|
|||
|
|
@ -376,12 +376,16 @@ namespace engine {
|
|||
class Turnout
|
||||
: public Port
|
||||
, public PAT
|
||||
//////////////////////////////OOO non-copyable? move-only??
|
||||
// , util::MoveOnly
|
||||
{
|
||||
using Feed = typename PAT::Feed;
|
||||
using PAT::PAT;
|
||||
|
||||
public:
|
||||
Turnout(Turnout&& rr) ////////////////////////////////////////////OOO investigation of MoveOnly and problems with the builder logic
|
||||
: Port(static_cast<Port&&>(rr))
|
||||
, PAT(static_cast<PAT&&>(rr))
|
||||
{ }
|
||||
|
||||
/**
|
||||
* Entrance point to the next recursive step of media processing.
|
||||
|
|
|
|||
|
|
@ -8665,9 +8665,7 @@
|
|||
</node>
|
||||
<node CREATED="1512955707636" ID="ID_398975798" MODIFIED="1512955789085" TEXT="aber bestehendes Verhalten ist gefährlich">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
die Builder-Operationen moven den bisherigen Iterator-compound weg.
|
||||
|
|
@ -10243,9 +10241,7 @@
|
|||
</node>
|
||||
<node CREATED="1512358965657" ID="ID_816120367" MODIFIED="1512359005565" TEXT="trotzdem... auch IterSnapshot">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...ist partiell diese Idee.
|
||||
|
|
@ -12165,9 +12161,7 @@
|
|||
</node>
|
||||
<node COLOR="#3b5a89" CREATED="1514292065333" FOLDED="true" ID="ID_1133433583" MODIFIED="1576282358120" TEXT="Frage: expliziter Test für path resolution?">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
macht es Sinn, dafür einen expliziten Testfall zu konstruieren,
|
||||
|
|
@ -12926,9 +12920,7 @@
|
|||
<node CREATED="1517012855604" FOLDED="true" ID="ID_1313395113" MODIFIED="1561827469153" TEXT="Pro">
|
||||
<node CREATED="1517012861315" ID="ID_1630656396" MODIFIED="1518487921068" TEXT="war ohnehin vorgesehen und notwendig">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...und zwar zwingend notwendig, weil es (viele) Views geben wird,
|
||||
|
|
@ -13652,9 +13644,7 @@
|
|||
</node>
|
||||
<node CREATED="1519439848624" FOLDED="true" ID="ID_1356890401" MODIFIED="1525124214959">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
kann man den Level <i>erschließen?</i>
|
||||
|
|
@ -14128,9 +14118,7 @@
|
|||
<node CREATED="1518212471553" FOLDED="true" ID="ID_1821401889" MODIFIED="1561827469155" TEXT="Frage: wann?">
|
||||
<node CREATED="1518212565636" ID="ID_1223770753" MODIFIED="1518487921070" TEXT="Lösen einer zu kurzen Klausel bringt nix">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...weil wir keinen Zustand sammeln
|
||||
|
|
@ -51021,9 +51009,7 @@
|
|||
</node>
|
||||
<node BACKGROUND_COLOR="#fefc4e" COLOR="#351d75" CREATED="1488677859619" HGAP="-15" ID="ID_827179653" MODIFIED="1576282357996" TEXT="Problem: Service-Zugang" VSHIFT="24">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...da dies ein pervasiv genutzter Service ist,
|
||||
|
|
@ -51174,9 +51160,7 @@
|
|||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1488937670778" ID="ID_696645875" MODIFIED="1576282357993" TEXT="fest hinterlegte Eintität einsetzen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...das UI weiß,
|
||||
|
|
@ -51195,9 +51179,7 @@
|
|||
</node>
|
||||
<node CREATED="1488937682649" ID="ID_1090053275" MODIFIED="1576282357993" TEXT="aktuelles Element (mit Typ-Check)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
vom Command her ist der Typ festgelegt
|
||||
|
|
@ -51216,9 +51198,7 @@
|
|||
</node>
|
||||
<node CREATED="1488937711053" ID="ID_586793367" MODIFIED="1576282357992" TEXT="partial application">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
eine Argumentliste mit mehreren Parametern wir Schritt für Schritt geschlossen
|
||||
|
|
@ -51228,9 +51208,7 @@
|
|||
</node>
|
||||
<node CREATED="1488937724867" ID="ID_231519502" MODIFIED="1576282357991" TEXT="Ordnung nach Scope">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
wenn mehrere Objekte als Argumente in Frage kommen,
|
||||
|
|
@ -89585,7 +89563,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</html></richcontent>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728870377629" ID="ID_616326824" MODIFIED="1728870428683" TEXT="Irgendetwas mit der move/realloc-Funktion in lib::SeveralBuilder ist nicht in Ordnung">
|
||||
<node COLOR="#435e98" CREATED="1728870377629" ID="ID_616326824" MODIFIED="1728914206823" TEXT="Irgendetwas mit der move/realloc-Funktion in lib::SeveralBuilder ist nicht in Ordnung">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -89596,10 +89574,305 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
         moveElem (size_t idx, Bucket* src, Bucket* tar)
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1728912300807" ID="ID_1640227081" MODIFIED="1728912306457" TEXT="Aufrufpfad">
|
||||
<node CREATED="1728912307941" ID="ID_969192361" MODIFIED="1728912409280" TEXT="aus NodeBuilder::ports.append(Turnout&&)">
|
||||
<node CREATED="1728912494848" ID="ID_855801852" MODIFIED="1728912613740">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
<font face="Monospaced" size="2">Turnout<SimpleWeavingPattern< </font>
|
||||
</p>
|
||||
<p>
|
||||
<font face="Monospaced" size="2">            Conf_DirectFunctionInvocation<1 </font>
|
||||
</p>
|
||||
<p>
|
||||
<font face="Monospaced" size="2">                                         ,void(array<char*,1>,array<char*,1>) >>></font>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1728912494851" MODIFIED="1728912494851" TEXT="I = steam::engine::Port"/>
|
||||
<node CREATED="1728912494851" MODIFIED="1728912494851" TEXT="E = steam::engine::Port"/>
|
||||
<node CREATED="1728912494851" MODIFIED="1728912494851" TEXT="POL = lib::allo::HeapOwn"/>
|
||||
</node>
|
||||
<node CREATED="1728912769541" ID="ID_93223074" MODIFIED="1728912807500" TEXT="emplace<TY>(TY&&) mit TY=Turnout<...>"/>
|
||||
<node CREATED="1728912887895" ID="ID_502255925" MODIFIED="1728912899153" TEXT="emplaceNewElm() mit Val = TY"/>
|
||||
<node CREATED="1728912960541" ID="ID_790746245" MODIFIED="1728912995200" TEXT="adjustStorage(cnt,spread) mit I ≡ E"/>
|
||||
<node CREATED="1728913042009" ID="ID_1953344041" MODIFIED="1728913048061" TEXT="Policy::realloc()">
|
||||
<node CREATED="1728913187349" ID="ID_833099828" MODIFIED="1728913187349" TEXT="lib::allo::AllocationPolicy<I, E, ALO>"/>
|
||||
<node CREATED="1728913199267" ID="ID_1776169148" MODIFIED="1728913201093" TEXT="mit I ≡ E"/>
|
||||
<node CREATED="1728913187349" ID="ID_1125386248" MODIFIED="1728913187349" TEXT="ALO = std::allocator;"/>
|
||||
<node CREATED="1728913187349" ID="ID_1265211055" MODIFIED="1728913187349" TEXT="Bucket = lib::several::ArrayBucket<Port>"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1728913436042" ID="ID_120683164" MODIFIED="1728913462905" TEXT="moveElm geht in den 3.Zweig">
|
||||
<node CREATED="1728913520979" ID="ID_1699922652" MODIFIED="1728913530388" TEXT="I ≡ E ≔ Port"/>
|
||||
<node CREATED="1728913535014" ID="ID_1128958329" MODIFIED="1728913545986" TEXT="Port ist sicher nicht trivially copyable"/>
|
||||
<node CREATED="1728913611190" ID="ID_1287561938" MODIFIED="1728913629720" TEXT="über die Kopierbarkeit des Interfaces (Port) ist nichts bekannt">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node CREATED="1728913633459" ID="ID_1767219058" MODIFIED="1728913673339">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
insofern verhält sich hier der Compiler<i> formal</i> und auch<i>  inhaltlich</i> <b>logisch korrekt</b>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1728913695699" ID="ID_1603489656" MODIFIED="1728913965774">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
<font color="#1210b0">Port</font> ◁— <b>Turnout</b>
|
||||
</p>
|
||||
<p>
|
||||
<font color="#7407d7">MoveOnly</font> ◁— CONF  ◁— SimpleWeavingPattern  ◁— <b>Turnout</b>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="info"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1728914001593" ID="ID_290756970" MODIFIED="1728914402212" TEXT="an Realloc hatte ich bisher nicht gedacht">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node CREATED="1728914214117" ID="ID_1379488298" MODIFIED="1728914227114" TEXT="im Test fängt das die Standard-Pre-Allokation von 10 Elementen auf"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1728914228920" ID="ID_1907870057" MODIFIED="1728914316325" TEXT="im Realbetrieb könnte es problematisch werden ">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1728913971453" ID="ID_852271835" MODIFIED="1728914059311" TEXT="Warnung abstellen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
indem man die Parameter in diesem Zweig voided
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<linktarget COLOR="#a9b4c1" DESTINATION="ID_852271835" ENDARROW="Default" ENDINCLINATION="19;47;" ID="Arrow_ID_495667234" SOURCE="ID_230526713" STARTARROW="None" STARTINCLINATION="69;8;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1728914038621" ID="ID_230526713" MODIFIED="1728914487132" TEXT="Warnung adäquat">
|
||||
<arrowlink DESTINATION="ID_852271835" ENDARROW="Default" ENDINCLINATION="19;47;" ID="Arrow_ID_495667234" STARTARROW="None" STARTINCLINATION="69;8;"/>
|
||||
<icon BUILTIN="clanbomber"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728914498759" ID="ID_283927094" MODIFIED="1728914523119" TEXT="Builder-Gebrauch und Speicherbelegung (⟶ realloc )">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node COLOR="#435e98" CREATED="1728914683488" ID="ID_204246046" MODIFIED="1728914794055" TEXT="ProcNode sind NonCopyable (müssen auch)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Da ProcNodes regelmäßig auf ihre Leads per direkter Referenz zugreifen, müssen sie sofort mit der Erzeugung im Speicher festgesetzt werden. Das war auch der Grund, warum ich den Builder in dieser limitierten Form aufgebaut habe: man muß sich zwangsläufig von den Quellen durch den Graphen aufwärts bewegen.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1728914795559" ID="ID_1052546340" MODIFIED="1728914842396" TEXT="⟹ aber alles was im Builder auftritt ist potentiell gefährlich">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node COLOR="#338800" CREATED="1728915136032" ID="ID_1049570342" MODIFIED="1728915170293" TEXT="BufferProvider sind OK (NonCopyable, DI als Service)">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1728915171699" ID="ID_1768778507" MODIFIED="1728915250561" TEXT="BuffDescriptor und BuffHandle sind explizit kopierbar">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1728918043717" ID="ID_828413139" MODIFIED="1728918052586" TEXT="Konzeptionelles Problem mit Port im Builder">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node CREATED="1728918063615" ID="ID_1224903798" MODIFIED="1728918076172" TEXT="Konflikt in mehrerlei Hinsichten">
|
||||
<node CREATED="1728918082390" ID="ID_200366040" MODIFIED="1728918186876" TEXT="Architektonisch betrachtet sollten alle Entitäten non-Copyable sein"/>
|
||||
<node CREATED="1728918225779" ID="ID_425950473" MODIFIED="1728918242221" TEXT="das steht im Widerspruch zum üblichen Builder-Definitionsschema">
|
||||
<node CREATED="1728918596625" ID="ID_937405626" MODIFIED="1728918624201" TEXT="insofern ein Builder ein Resultat zurückliefert"/>
|
||||
<node CREATED="1728918625957" ID="ID_709289044" MODIFIED="1728918781196" TEXT="Klassen aus Member/Parent aufbauen (keine Referenz)"/>
|
||||
<node CREATED="1728918731887" ID="ID_1520143853" MODIFIED="1728918743048" TEXT="Sub-Builder für Teilkomponenten verwenden"/>
|
||||
<node CREATED="1728918892338" ID="ID_1933445570" MODIFIED="1728919094490" TEXT="stateless / immutable Objects">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
»one-shot«-Konstruktor, Objekte werden nur in den Definitionslisten erzeugt. Das erfordert entweder, extrem viele Detail-Konstruktorparameter durchzureichen (Problem der Verkopplung), oder eben ganze Teilkomponenten per RValue-Ref entgegenzunehmen und an den Zielpunkt zu schieben
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1728918821443" ID="ID_1466886872" MODIFIED="1728918825494" TEXT="Ausweg">
|
||||
<node CREATED="1728918826658" ID="ID_1610131618" MODIFIED="1728918837787" TEXT="Builder der per Seiteneffekt generiert"/>
|
||||
<node CREATED="1728918840960" ID="ID_1830061934" MODIFIED="1728918884189" TEXT="Teleskop-Konstuktor der alle Teilkomponenten direkt baut"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1728918387245" ID="ID_188010599" MODIFIED="1728918420109" TEXT="außerdem: lib::SeveralBuilder braucht nothrow-Movable für ein realloc()"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1728918432543" ID="ID_1719167814" MODIFIED="1728921685603" TEXT="und konkret verhält sich der Compiler überraschend (Copy-Konstruktor)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Und dieser Compiler ist alt: ich sitze auf einer 4 Jahre veralteten Plattform.
|
||||
</p>
|
||||
<p>
|
||||
Aufgrund der Komplexität der aufgebauten Strukturen ist nicht ersichtlich, ob der Compiler sich korrekt verhält; jedenfalls versucht er, den <b>Copy-Konstruktor</b> von engine::Turnout zu verwenden
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node CREATED="1728921691001" ID="ID_369047782" MODIFIED="1728921712680" TEXT="er beseht darauf, für Port den Copy-Konstruktor aufzurufen"/>
|
||||
<node CREATED="1728921713967" ID="ID_840072193" MODIFIED="1728921744509" TEXT="selbst wenn ich explizit in Turnout einen Move-Konstruktor anschreibe"/>
|
||||
<node CREATED="1728922003091" ID="ID_947084085" MODIFIED="1728922021542" TEXT="Grund: explizit deklarierter Destruktor">
|
||||
<icon BUILTIN="info"/>
|
||||
<node CREATED="1728922025973" ID="ID_680965500" MODIFIED="1728922050645" TEXT="habe ich nach meinem Standard-Schema so gemacht">
|
||||
<node CREATED="1728922282946" ID="ID_1363255304" MODIFIED="1728922288421" TEXT="ist auch notwendig"/>
|
||||
<node CREATED="1728922295305" ID="ID_730483507" MODIFIED="1728922364523" TEXT="denn im Template-Code schreibt man typischerweise die virtuellen Methoden inline"/>
|
||||
<node CREATED="1728922365989" ID="ID_1155260812" MODIFIED="1728922439999" TEXT="und dann emittiert u.U. der Compiler keine VTable (ist tatsächlich ein Problem hier">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
das ist hinlänglich bekannt, und deshalb mache ich es routinemäßig so; habe es aber nochmal explizit versucht, und das Problem tritt auf. Das wäre erst gelöst, wenn wir auf Module umstellen würden
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="broken-line"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1728922055592" ID="ID_35677607" MODIFIED="1728922210152" TEXT="es gibt eine Regel in C++ für automatisch generierte Move-Konstruktoren">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...sobald ein Copy-Konstruktor oder Destruktor explizit definiert ist, wird der Compiler keinen Move-Konstruktor mehr generieren (sondern ggfs. nur noch einen Copy-Konstruktor). Die Begründung dafür ist, daß in einem solchen Fall wahrscheinlich der default-generierte move-Konstruktor subtil oder gefährlich falsch sein könnte
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1728922453819" ID="ID_854132229" MODIFIED="1728922545653" TEXT="müßte dann explizit diese Konstruktoren deklarieren">
|
||||
<arrowlink COLOR="#e8ffd5" DESTINATION="ID_1240656293" ENDARROW="Default" ENDINCLINATION="48;-247;" ID="Arrow_ID_383730101" STARTARROW="None" STARTINCLINATION="-552;28;"/>
|
||||
<icon BUILTIN="smily_bad"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1728919511214" ID="ID_717691514" MODIFIED="1728919518364" TEXT="Lösungs-Strategien">
|
||||
<node CREATED="1728919519861" ID="ID_893369954" MODIFIED="1728919531258" TEXT="Port tatsächlich non-copyable machen">
|
||||
<node CREATED="1728919575373" ID="ID_1789193481" MODIFIED="1728919601059" TEXT="dann müßte der WeavingBuilder per Seiteneffekt in emplacen">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1728919603437" ID="ID_1351297042" MODIFIED="1728919611061" TEXT="das wäre definitiv machbar"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728919612233" ID="ID_10047786" MODIFIED="1728919761204" TEXT="und zwar ohne großen Aufwand">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
man müßte lediglich der build()-Methode explizit einen SeveralBuilder übergeben; das ließe sich sogar generalisieren auf etwas Generisches, das eine emplace()-Methode bietet; in erster Näherung (C++17) wäre das ein offener Template-Parameter
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728919724334" ID="ID_1429006329" MODIFIED="1728919748503" TEXT="Bleibt aber das Problem mit realloc()">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1728919780226" ID="ID_459933288" MODIFIED="1728920202861" TEXT="die »Hintertür« funktioniert nur für die aktuell neueste Allokation">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
mit »Hintertür« meine ich die Fähigkeit zum dynamischen Wachsen der Allokation speziell im Allocation-Cluster; das ist leicht möglich, aber nur indem wir die aktuell neueste Allokation im Rahmen eines Bucket nachjustieren
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1728920206175" ID="ID_1988845099" MODIFIED="1728920273724" TEXT="aber der nested-Builder bewirkt verschachtelte Allokations-Anforderungen"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1728920314192" ID="ID_147357026" MODIFIED="1728920324731" TEXT="Lösungen">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1728920326985" ID="ID_548153639" MODIFIED="1728920342770" TEXT="benötigte Anzahl zu Beginn verbindlich festsetzen"/>
|
||||
<node CREATED="1728920344206" ID="ID_337652041" MODIFIED="1728920686754" TEXT="trickreichen Aufruf, der alle Builder in einem Lauf abfeuert">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<ul>
|
||||
<li>
|
||||
einfach: man hat eine Deque mit allen Buildern; erst zum Abschluß werden alle diese Builder in einem Lauf in das Several<Port> entladen; das könnte dann nur in der finalen build()-Methode für die Node stattfinden
|
||||
</li>
|
||||
<li>
|
||||
trickreich? könnte man ggfs etwas mit Tail-Rekursion »zaubern«?
|
||||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1728920705824" ID="ID_1896772759" MODIFIED="1728920715408" TEXT="Port wird MoveOnlyNothrow">
|
||||
<node CREATED="1728920716828" ID="ID_1775685257" MODIFIED="1728920798837" TEXT="»MoveOnlyNothrow« wäre dann eine neue Variante">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
es könnte vielleicht sogar die Standard-Variante sein, aber so eine Änderung wäre massiv, und könnte mehrere Wochen Arbeit nach sich ziehen und am Ende doch scheitern. Also wäre das dann ein weiteres Ewigkeits-Projekt (als hätten wir nicht genug von der Sorte)
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1728920871071" ID="ID_358330215" MODIFIED="1728920885026" TEXT="das ganze Builder-Schema bleibt so wie es ist"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1728920893861" ID="ID_563974492" MODIFIED="1728920908958" TEXT="Port würde man sich dann am Abgrund bewegen">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1728920911699" ID="ID_226962231" MODIFIED="1728920927731" TEXT="es geht, weil Port-Referenzen sich stets auf bereits gebaute Nodes beziehen"/>
|
||||
<node CREATED="1728920928976" ID="ID_1711841513" MODIFIED="1728920975557" TEXT="das muß man aber wissen...">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
jedermann könnte jederzeit Port-Referenzen in anderen Umgständen erzeugen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1728921085563" ID="ID_1240656293" MODIFIED="1728922531582" TEXT="Status-quo : nur das PAT ist moveOnly">
|
||||
<linktarget COLOR="#e8ffd5" DESTINATION="ID_1240656293" ENDARROW="Default" ENDINCLINATION="48;-247;" ID="Arrow_ID_383730101" SOURCE="ID_854132229" STARTARROW="None" STARTINCLINATION="-552;28;"/>
|
||||
<node CREATED="1728921114799" ID="ID_8142965" MODIFIED="1728921127761" TEXT="auch hier müßte man letztlich ein MoveOnlyNothrow einführen"/>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728921157089" ID="ID_1600081549" MODIFIED="1728921342782" TEXT="und der Several-Builder muß das wissen">
|
||||
<arrowlink COLOR="#eb115c" DESTINATION="ID_690402795" ENDARROW="Default" ENDINCLINATION="11;-7;" ID="Arrow_ID_983406969" STARTARROW="None" STARTINCLINATION="-5;9;"/>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1728921171892" ID="ID_1252631310" MODIFIED="1728921184538" TEXT="Konsistenz-Problem mit dem aktuellen Stand">
|
||||
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1728921193764" ID="ID_690402795" MODIFIED="1728921344029" TEXT="der Several-Builder arbeitet mit I ≡ E ≔ Port">
|
||||
<linktarget COLOR="#eb115c" DESTINATION="ID_690402795" ENDARROW="Default" ENDINCLINATION="11;-7;" ID="Arrow_ID_983406969" SOURCE="ID_1600081549" STARTARROW="None" STARTINCLINATION="-5;9;"/>
|
||||
<icon BUILTIN="broken-line"/>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1728921314268" ID="ID_1057362951" MODIFIED="1728921323407" TEXT="warum eigentlich?">
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1728921407026" ID="ID_1988539921" MODIFIED="1728921416272" TEXT="WeavingBuilder::build() ist auto"/>
|
||||
<node CREATED="1728921417310" ID="ID_1211882082" MODIFIED="1728921449333" TEXT="„sollte doch“ einen Turnout liefern"/>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1728921453763" ID="ID_1928466246" MODIFIED="1728921475471" TEXT="ich hätte erwartet, daß SeveralBuilder das aufgreift">
|
||||
<icon BUILTIN="flag-pink"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1728921324643" ID="ID_1723172951" MODIFIED="1728921332417" TEXT="das kann doch gar nicht funktionieren!"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1728870929451" ID="ID_1740846481" MODIFIED="1728870951984" TEXT="der Gebrauch des BuffHandle::accessAs<TY>() ist zweifelhaft">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1728870953831" ID="ID_1005617048" MODIFIED="1728870963978" TEXT="ich bekomme einen LInker-Fehler"/>
|
||||
|
|
@ -89746,8 +90019,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
...weil es immer mehr darauf hinaus läuft, daß der PortBuilder die high-level-Sicht auf die Verdrahtung hat, während der WeavingBuilder von ersterem explizit gesteuert werden muß
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1728861676015" ID="ID_865228634" MODIFIED="1728861963334" TEXT="da habe ich für den Prototypen zu stark vereinfacht">
|
||||
<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"/>
|
||||
|
|
|
|||
Loading…
Reference in a new issue