diff --git a/src/lib/hetero-data.hpp b/src/lib/hetero-data.hpp index 652e846ec..8413bf183 100644 --- a/src/lib/hetero-data.hpp +++ b/src/lib/hetero-data.hpp @@ -42,14 +42,15 @@ #define LIB_HETERO_DATA_H -//#include "lib/error.hpp" +#include "lib/error.hpp" //#include "lib/symbol.hpp" #include "lib/nocopy.hpp" -#include "lib/linked-elements.hpp" +//#include "lib/linked-elements.hpp" #include "lib/meta/typelist.hpp" //#include //#include +#include namespace lib { @@ -63,6 +64,7 @@ namespace lib { struct StorageFrame : StorageLoc , std::tuple + , util::NonCopyable { }; @@ -77,18 +79,59 @@ namespace lib { template class HeteroData,TAIL>> - : protected StorageFrame + : StorageFrame { - public: - size_t constexpr size(); + using _Self = HeteroData; + using _Tail = HeteroData; + using Frame = StorageFrame; + + static constexpr size_t localSiz = sizeof...(DATA); template + static constexpr bool isLocal = slot < localSiz; + + _Tail& + accessTail() + { + REQUIRE (Frame::next, "HeteroData storage logic broken: follow-up extent not yet allocated"); + return * reinterpret_cast<_Tail*> (Frame::next); + } + + public: + static constexpr size_t + size() + { + return localSiz + _Tail::size(); + } + + template + using Elm_t = std::conditional, std::tuple_element_t + , typename _Tail::template Elm_t>; + + template + Elm_t& + get() + { + static_assert (slot < size(), "HeteroData access index beyond defined data"); + if constexpr (slot < localSiz) + return std::get (*this); + else + return accessTail().template get(); + } + struct Navigator { }; }; + template<> + class HeteroData + { + public: + static size_t constexpr size() { return 0; } + }; + } // namespace lib #endif /*LIB_HETERO_DATA_H*/ diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index e377e536b..1417e5252 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -21111,9 +21111,7 @@ - - - +

will sagen: es gibt keinen Zugriff, der vom Canvas ausgeht, durch die TrackBodies durchsteigt, und dann indirekt in den Cavas zurück greift. Denn -- zumindest im Moment -- handelt es sich um zwei klar geschiedene Belange: einmal das Rendern der Track-Struktur, und andererseits das platzieren von Clips auf dem Canvas @@ -21543,9 +21541,7 @@ - - - +

int hookAdjY (int yPos)  override { return yPos + body_.getContentOffsetY(); }; @@ -22091,9 +22087,7 @@ - - - +

Ursache ist ein schiefes Design @@ -22905,9 +22899,7 @@ - - - +

"was kann denn schon passieren??" @@ -23692,9 +23684,7 @@ - - - +

es ist hier kein by-Name-Zugriff, @@ -25813,9 +25803,7 @@ - - - +

Streng genommen würden wir in der Tat einen generischen Quer-Zugriffsmechanismus brauchen. @@ -29411,9 +29399,7 @@ - - - +

...jeodch nicht eigens im Test dokumentiert @@ -33102,9 +33088,7 @@ - - - +

  • @@ -37451,9 +37435,7 @@ - - - +

    im Beispiel: in dieser Closure wird zunächste eine Verdrahtung auf das button_down-Event angelegt. Wenn diese aktiviert wird, schaltet die die Beobachtung eines ebenfalls vorsorglich verdrahteten motion_notify_event ein, sowie analog das Warten auf ein button_up @@ -39389,9 +39371,7 @@ - - - +

    der Gesten-Controller sollte hier nicht mitmischen @@ -40307,9 +40287,7 @@ - - - +

    aber time::Control ist nur auf Zeiten ausgelegt @@ -40685,9 +40663,7 @@ - - - +

    insofern muß es dann aber auch mit maximal großen Integer-Zahlen noch sauber funktionieren @@ -40937,9 +40913,7 @@ - - - +

    einmal stark reinzoomen, und dann wieder zurück ⟹ Bereich ist beschnitten und kleiner geworden; das ist lästig, weil die nächst größere Stufe deutlich größer ist; meiner Einschätzung nach wäre es weniger lästig, wenn man ein kleines bischen zu viel sieht, zumal sich das auf der nächsten Zweierpotenz einpendeln dürfte @@ -41205,9 +41179,7 @@ - - - +

    • @@ -87527,8 +87499,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      der Build-Prozeß belegt sukzessiv mehrere abstrakte Slots

      - - + @@ -87658,8 +87629,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      ...das wäre fatal, denn dann würde die Abstraktion zusammenbrechen; etweder der Builder, oder (noch schlimmer) das Library-Plug-in müßte Render-Engine-Internals instrumentieren

      - - +       @@ -87732,8 +87702,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      Damit wäre nämlich eine relativ sichere Storage auf dem Stack gegeben, und die Gegenwart der Parameter wäre trotzdem stets eindeutig dokumentiert. Auch im Hinblick darauf, daß vermutlich sehr häufig irgend welche Parameter fest gesetzt werden müssen (aber nicht per Automation bestimmt)

      - - +       @@ -87743,8 +87712,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      die explizite Behandlung würde damit in das konkrete Weaving-Pattern verlegt

      - -       + @@ -87771,8 +87739,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      in diesem Fall hätten alle Bindings die gleiche Port-Subklasse, würden aber beim Zugriff auf die Parameter einen virtual call machen

      - - +       @@ -87812,8 +87779,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      Ich wollte mehr, und deshalb halte ich die Stelle für das TurnoutSystem offen — obwohl auf gegenwärtigem Stand seine verbleibende Funktionalität komplett in die interne Mechanik integriert werden könnte. Auf diesem gegenwärtigen Stand kann ich die Vorstellung noch nicht weiter entwickeln, weil mir der klare Blick auf den realen Gebrauch in den tatsächlichen Proportionen fehlt — aber ich hoffe, daß sich dann aus dem Einsatz eines Baukasten-Systems irgendwann klarere Muster codifizieren lassen

      - - +       @@ -87830,8 +87796,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      Fazit: zurück zum ersten Konzept

      - - + @@ -87855,8 +87820,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      einen Satz Parameter an anderer Stelle platzieren und anhängen

      - - +       @@ -87868,8 +87832,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      Der Zugriff erfolgt unchecked, aber ein typsicherer Zugriff soll durch einen compile-time-Overlay gewährleistet sein. Essentiell ist, daß die typsicheren Accessoren erzeugt werden können bevor die konkrete Storage-Adressen bekannt sind

      - - +       @@ -87886,6 +87849,29 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
       + + + + + + + + + + + + +

      + der Umweg über lib::LinkedElements ist überflüssig, zumal ich durch direkte rekursive Implementierung auch noch eine klare Fehlermeldung erzeugen kann, falls ein Nachfolge-Extent noch nicht alloziert wurde +

      + + +       +       +       +       + + @@ -87893,7 +87879,6 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
             -