From eed0f55f838f07586da715fc6f59cca005aa7071 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 10 Dec 2024 23:23:41 +0100 Subject: [PATCH] Invocation: rearrange (and fix) front-End constructor MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * now yields an instance of the full `HeteroData` template * work around problems with std::tuple_element_t for derived classes Can now default-create and direct-init a front-End data block, access and modify its elements — and the API looks ok-ish for me --- src/lib/hetero-data.hpp | 15 ++- tests/library/hetero-data-test.cpp | 19 +++- wiki/thinkPad.ichthyo.mm | 147 +++++++++++++++++------------ 3 files changed, 110 insertions(+), 71 deletions(-) diff --git a/src/lib/hetero-data.hpp b/src/lib/hetero-data.hpp index f92748cd4..c6bf07c27 100644 --- a/src/lib/hetero-data.hpp +++ b/src/lib/hetero-data.hpp @@ -49,9 +49,11 @@ #include "lib/meta/typelist.hpp" #include "lib/meta/typelist-manip.hpp" #include "lib/meta/typeseq-util.hpp" +#include "lib/test/test-helper.hpp" //#include //#include +#include #include @@ -65,7 +67,7 @@ namespace lib { template struct StorageFrame - : StorageLoc + : protected StorageLoc , std::tuple { using std::tuple::tuple; @@ -82,6 +84,7 @@ namespace lib { { using _Self = HeteroData; using _Tail = HeteroData; + using Tuple = std::tuple; using Frame = StorageFrame; static constexpr size_t localSiz = sizeof...(DATA); @@ -99,7 +102,11 @@ namespace lib { template friend class HeteroData; ///< allow chained types to use recursive type definitions + using Frame::Frame; + public: + HeteroData() = default; + static constexpr size_t size() { @@ -107,8 +114,8 @@ namespace lib { } template - using Elm_t = std::conditional, std::tuple_element_t - , typename _Tail::template Elm_t>; + using Elm_t = std::conditional_t, std::tuple_element_t + , typename _Tail::template Elm_t>; template Elm_t& @@ -180,7 +187,7 @@ namespace lib { using ChainType = _Front; template - static NewFrame + static _Front build (INIT&& ...initArgs) { return {initArgs ...}; diff --git a/tests/library/hetero-data-test.cpp b/tests/library/hetero-data-test.cpp index a8803412f..c787dbdb4 100644 --- a/tests/library/hetero-data-test.cpp +++ b/tests/library/hetero-data-test.cpp @@ -32,6 +32,8 @@ namespace test{ }//(End) test data + #define TYPE(_EXPR_) showType() + @@ -51,19 +53,26 @@ namespace test{ // seedRand(); // checksum = 0; - checkSingleKill(); + verify_FrontBlock(); } void - checkSingleKill () + verify_FrontBlock () { using Block1 = HeteroData; - CHECK ((is_Subclass>())); + CHECK ((is_Subclass>())); auto b1 = Block1::build (42, 1.61803); -SHOW_EXPR(b1) - CHECK (1.61803 == std::get<1> (b1)); + CHECK (1.61803 == b1.get<1>()); + CHECK (42 == b1.get<0>()); + CHECK (showType>() == "uint"_expect); + CHECK (showType>() == "double"_expect); + + Block1 b2; + CHECK (0.0 == b2.get<1>()); + b2.get<1>() = 3.14; + CHECK (3.14 == b2.get<1>()); } }; diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index f878d8dfa..3b936008d 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -21845,9 +21845,7 @@ - - - +

...und letztlich habe ich sie auch im Code komplett getrennt. CanvasHook und ViewHook haben nichts (mehr) miteinander zu tun @@ -22381,9 +22379,7 @@ - - - +

korrekt wäre, die Diff-Verben mitzulesen. @@ -22945,9 +22941,7 @@ - - - +

einen Fall, der praktisch nie auftritt @@ -23367,9 +23361,7 @@ - - - +

  • @@ -24635,9 +24627,7 @@ - - - +

    hängen garnicht direkt damit zusammen, sondern wurden getriggert durch den "unorthodoxen" Gebrauch des PtrDerefIter @@ -26744,9 +26734,7 @@ - - - +

    ...denn das Patchbay-Widget muß diverse Interna des Tracks beachten, @@ -29833,9 +29821,7 @@ - - - +

    • @@ -32384,9 +32370,7 @@ - - - +

      Wir erzeugen künstlich einen widget-Path und verankern ihn sinngemäß an der logisch richtigen Stelle (wobei aber die im Pfad aufgeführten Widgets gar nicht existieren, sondern logische Platzhalter sind). Über diesen Widget-Path greifen wir in einen CSS-Scope hinein, der typischerweise alle seine Styles von umschließenden Scopes erbt; indirekt ist damit aber auch die Möglichkeit geschaffen, diesen speziellen Scope gezielt mit CSS-Regeln zu addressieren — wodurch der Designer direkt auf das Erscheinungbild von Lumiera Einfluß nehmen kann @@ -36538,9 +36522,7 @@ - - - +

      Main erbt nicht von Gio::Application @@ -38803,9 +38785,7 @@ - - - +

      (gtypes.h): Provide type definitions for commonly used types. @@ -39518,9 +39498,7 @@ - - - +

      es ist total an das Framework gebunden @@ -40110,9 +40088,7 @@ - - - +

      ...dann müssen wir die Vorgabe speichern, und in jedem Schritt korrigierend eingreifen @@ -40384,9 +40360,7 @@ - - - +

      und so ist es auch gedacht: TimeVar sollte nicht auf APIs auftauchen! @@ -40660,9 +40634,7 @@ - - - +

      ...zunächst habe ich hier immer nur das Minimale getan, nämlich 1 µTick aufgeweitet; dies würde zwar funktionieren, aber in der Regel nicht zu einem praktikablen Verhalten führen — wohingegen der DEFAULT_CANVAS  so gewählt ist, daß er klein und handlich ist @@ -87752,8 +87724,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
      - - + + @@ -87781,18 +87753,22 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
             - - - - + + + + - - + + + + + + - - + + @@ -87872,7 +87848,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
       - + @@ -87889,7 +87865,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
       - + @@ -88160,20 +88136,67 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
             - + + - - + + + + +

      + ...der Standard-Fall nimmt N... Template-Argumente und macht daraus ein Tupel +

      + +             - + + + + +

      + ...das ist dann die einzige Typ-Signatur, die der Benutzer selber schreiben muß: HeteroData<X,Y,Z> +

      + + +       +       +       + + + - - - - + + + + + + + + + + + +

      + Das ist jetzt eine gewisse Asymetrie, die aber m.E. weniger wiegt, als der Vorteil, daß der angeschriebene HeteroData-Typ auch tatsächlich das ist, was für das Front-End erzeugt wird — notwendig wäre das überhaupt nicht, aber ohne Kenntnis der Definitionen wäre ein solches Verhalten hochgradig verwirrend; immerhin gehe ich davon aus, daß 90% der Leser nur den Standard-Fall sehen, und sich dann merken „das ist so eine Art Tupel...“ +

      + +       +       + + + + +

      + denn wir haben ja alle expliziten Accessor-Funktionen direkt auf dem Objekt nochmal definiert, und zudem wird das C++ Tuple-Protokoll implementiert +

      + + +       +       +