diff --git a/src/lib/several-builder.hpp b/src/lib/several-builder.hpp index afef23059..b54f0de8d 100644 --- a/src/lib/several-builder.hpp +++ b/src/lib/several-builder.hpp @@ -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 diff --git a/src/steam/engine/proc-node.hpp b/src/steam/engine/proc-node.hpp index e091fe10a..030fdb2ab 100644 --- a/src/steam/engine/proc-node.hpp +++ b/src/steam/engine/proc-node.hpp @@ -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; diff --git a/src/steam/engine/turnout.hpp b/src/steam/engine/turnout.hpp index 20b16d937..03d3eb2c7 100644 --- a/src/steam/engine/turnout.hpp +++ b/src/steam/engine/turnout.hpp @@ -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(rr)) + , PAT(static_cast(rr)) + { } /** * Entrance point to the next recursive step of media processing. diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index be37f6053..5214ff9fd 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -8665,9 +8665,7 @@ - - - +

die Builder-Operationen moven den bisherigen Iterator-compound weg. @@ -10243,9 +10241,7 @@ - - - +

...ist partiell diese Idee. @@ -12165,9 +12161,7 @@ - - - +

macht es Sinn, dafür einen expliziten Testfall zu konstruieren, @@ -12926,9 +12920,7 @@ - - - +

...und zwar zwingend notwendig, weil es (viele) Views geben wird, @@ -13652,9 +13644,7 @@ - - - +

kann man den Level erschließen? @@ -14128,9 +14118,7 @@ - - - +

...weil wir keinen Zustand sammeln @@ -51021,9 +51009,7 @@ - - - +

...da dies ein pervasiv genutzter Service ist, @@ -51174,9 +51160,7 @@ - - - +

...das UI weiß, @@ -51195,9 +51179,7 @@ - - - +

vom Command her ist der Typ festgelegt @@ -51216,9 +51198,7 @@ - - - +

eine Argumentliste mit mehreren Parametern wir Schritt für Schritt geschlossen @@ -51228,9 +51208,7 @@ - - - +

wenn mehrere Objekte als Argumente in Frage kommen, @@ -89585,7 +89563,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + @@ -89596,10 +89574,305 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
         moveElem (size_t idx, Bucket* src, Bucket* tar)

+ + + + + + + + + +

+ Turnout<SimpleWeavingPattern< +

+

+             Conf_DirectFunctionInvocation<1 +

+

+                                          ,void(array<char*,1>,array<char*,1>) >>> +

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

+ insofern verhält sich hier der Compiler formal und auch  inhaltlich logisch korrekt +

+ + + + + + + + +

+ Port ◁— Turnout +

+

+ MoveOnly ◁— CONF  ◁— SimpleWeavingPattern  ◁— Turnout +

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

+ indem man die Parameter in diesem Zweig voided +

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

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

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

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

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

+ Und dieser Compiler ist alt: ich sitze auf einer 4 Jahre veralteten Plattform. +

+

+ Aufgrund der Komplexität der aufgebauten Strukturen ist nicht ersichtlich, ob der Compiler sich korrekt verhält; jedenfalls versucht er, den Copy-Konstruktor von engine::Turnout zu verwenden +

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

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

+ + + + + + + + + +

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

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

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

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

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

+ + + + + + + + + + + + +
    +
  • + 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 +
    • +
  • + trickreich? könnte man ggfs etwas mit Tail-Rekursion »zaubern«? +
    • +
+ + + + + + + + + + + +

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

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

+ jedermann könnte jederzeit Port-Referenzen in anderen Umgständen erzeugen +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -89746,8 +90019,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
...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ß

- - +