Invocation: rearrange (and fix) front-End constructor

* now yields an instance of the full `HeteroData<X,X,Z>` 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
This commit is contained in:
Fischlurch 2024-12-10 23:23:41 +01:00
parent 510c39091d
commit eed0f55f83
3 changed files with 110 additions and 71 deletions

View file

@ -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 <algorithm>
//#include <vector>
#include <utility>
#include <tuple>
@ -65,7 +67,7 @@ namespace lib {
template<typename...DATA>
struct StorageFrame
: StorageLoc
: protected StorageLoc
, std::tuple<DATA...>
{
using std::tuple<DATA...>::tuple;
@ -82,6 +84,7 @@ namespace lib {
{
using _Self = HeteroData;
using _Tail = HeteroData<TAIL>;
using Tuple = std::tuple<DATA...>;
using Frame = StorageFrame<DATA...>;
static constexpr size_t localSiz = sizeof...(DATA);
@ -99,7 +102,11 @@ namespace lib {
template<typename...XX>
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<size_t slot>
using Elm_t = std::conditional<isLocal<slot>, std::tuple_element_t<slot,Frame>
, typename _Tail::template Elm_t<slot-localSiz>>;
using Elm_t = std::conditional_t<isLocal<slot>, std::tuple_element_t<slot,Tuple>
, typename _Tail::template Elm_t<slot-localSiz>>;
template<size_t slot>
Elm_t<slot>&
@ -180,7 +187,7 @@ namespace lib {
using ChainType = _Front;
template<typename...INIT>
static NewFrame
static _Front
build (INIT&& ...initArgs)
{
return {initArgs ...};

View file

@ -32,6 +32,8 @@ namespace test{
}//(End) test data
#define TYPE(_EXPR_) showType<decltype(_EXPR_)>()
@ -51,19 +53,26 @@ namespace test{
// seedRand();
// checksum = 0;
checkSingleKill();
verify_FrontBlock();
}
void
checkSingleKill ()
verify_FrontBlock ()
{
using Block1 = HeteroData<uint,double>;
CHECK ((is_Subclass<Block1, std::tuple<uint,double>>()));
CHECK ((is_Subclass<Block1::NewFrame, std::tuple<uint,double>>()));
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<Block1::Elm_t<0>>() == "uint"_expect);
CHECK (showType<Block1::Elm_t<1>>() == "double"_expect);
Block1 b2;
CHECK (0.0 == b2.get<1>());
b2.get<1>() = 3.14;
CHECK (3.14 == b2.get<1>());
}
};

View file

@ -21845,9 +21845,7 @@
</node>
<node CREATED="1666476057276" ID="ID_1151114899" MODIFIED="1666476103630" TEXT="es sind also zwei getrennte (strukturell &#xe4;nliche F&#xe4;lle)">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...und letztlich habe ich sie auch im Code komplett getrennt. CanvasHook und ViewHook haben nichts (mehr) miteinander zu tun
@ -22381,9 +22379,7 @@
</node>
<node CREATED="1480123478013" ID="ID_1281325973" MODIFIED="1576282358086" TEXT="eine Ebene zu tief, aber geht noch">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
korrekt w&#228;re, die Diff-Verben mitzulesen.
@ -22945,9 +22941,7 @@
</node>
<node CREATED="1480778768988" ID="ID_1385067618" MODIFIED="1576282358078" TEXT="und das alles nur f&#xfc;r....">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
einen Fall, der <i>praktisch nie</i>&#160;auftritt
@ -23367,9 +23361,7 @@
</body>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<ul>
<li>
@ -24635,9 +24627,7 @@
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1583606385337" ID="ID_1117598680" MODIFIED="1583626259305" TEXT="Type-deduction-Probleme">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
h&#228;ngen garnicht direkt damit zusammen, sondern wurden getriggert durch den &quot;unorthodoxen&quot; Gebrauch des PtrDerefIter
@ -26744,9 +26734,7 @@
<node CREATED="1540747533463" ID="ID_1845120165" MODIFIED="1557498707227" TEXT="dann w&#xe4;re TimelineHeader == PatchbayWidget"/>
<node CREATED="1540747550734" ID="ID_843399235" MODIFIED="1576282358067" TEXT="macht Sinn...">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn das Patchbay-Widget mu&#223; diverse Interna des Tracks beachten,
@ -29833,9 +29821,7 @@
</node>
<node BACKGROUND_COLOR="#c6ccd6" COLOR="#2c2a74" CREATED="1672843882154" ID="ID_1978068021" MODIFIED="1676045024820" TEXT="Beachte Unterschiede in der Bedeutung der Getter">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<ul>
<li>
@ -32384,9 +32370,7 @@
</node>
<node COLOR="#435e98" CREATED="1678462308282" ID="ID_1157002655" MODIFIED="1679011586549" TEXT="L&#xf6;sung: virtueller widget-Path &#x201e;fischt&#x201c; im gegebenen CSS-Kontext">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Wir erzeugen k&#252;nstlich einen widget-Path und verankern ihn sinngem&#228;&#223; an der logisch richtigen Stelle (wobei aber die im Pfad aufgef&#252;hrten Widgets gar nicht existieren, sondern logische Platzhalter sind). &#220;ber diesen Widget-Path greifen wir in einen CSS-Scope hinein, der typischerweise alle seine Styles von umschlie&#223;enden Scopes erbt; indirekt ist damit aber auch die M&#246;glichkeit geschaffen, diesen speziellen Scope gezielt mit CSS-Regeln zu addressieren &#8212; wodurch der Designer direkt auf das Erscheinungbild von Lumiera Einflu&#223; nehmen kann
@ -36538,9 +36522,7 @@
<node CREATED="1533301567374" ID="ID_34255114" MODIFIED="1561827465300" TEXT="hatte Gtk::Main das?">
<node CREATED="1533302102181" ID="ID_1070266886" MODIFIED="1533302125340">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
Main <b>erbt nicht</b>&#160;von Gio::Application
@ -38803,9 +38785,7 @@
<node CREATED="1618677381682" ID="ID_1297330759" MODIFIED="1618677391341" TEXT="GTK f&#xfc;hrt hier einen &quot;gdouble&quot; ein"/>
<node CREATED="1618677393499" ID="ID_1949606460" MODIFIED="1618677453343" TEXT="Grund ist Portabilit&#xe4;t">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
<u>(gtypes.h)</u>: Provide type definitions for commonly used types.
@ -39518,9 +39498,7 @@
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1618499388465" ID="ID_540657197" MODIFIED="1618499424481" TEXT="Problem: wie kann man dies einkapseln?">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
es ist total an das Framework gebunden
@ -40110,9 +40088,7 @@
</node>
<node CREATED="1667255234369" ID="ID_713280456" MODIFIED="1667255281215" TEXT="falls das nicht klappt....">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...dann m&#252;ssen wir die Vorgabe speichern, und in jedem Schritt korrigierend eingreifen
@ -40384,9 +40360,7 @@
<node CREATED="1667156173714" ID="ID_1596347322" MODIFIED="1667156188388" TEXT="das w&#xfc;rde der fluiden Verwendung schaden"/>
<node CREATED="1667156513645" ID="ID_1002330972" MODIFIED="1667156696839" TEXT="m&#xe4;&#xdf;ig gef&#xe4;hrlich, solange TimeVar ehr selten und lokal begrenzt">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
und so ist es auch gedacht: TimeVar sollte nicht auf APIs auftauchen!
@ -40660,9 +40634,7 @@
<node CREATED="1667667111845" ID="ID_240814651" MODIFIED="1667667131096" TEXT="Input kann nur leer sein, nicht negativ"/>
<node CREATED="1667667143969" ID="ID_971076298" MODIFIED="1667667564598" TEXT="falls leer, weite aus auf DEFAULT_CANVAS (&#x2259; 23sec)">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...zun&#228;chst habe ich hier immer nur das Minimale getan, n&#228;mlich 1 &#181;Tick aufgeweitet; dies w&#252;rde zwar funktionieren, aber in der Regel nicht zu einem praktikablen Verhalten f&#252;hren &#8212; wohingegen der <i>DEFAULT_CANVAS</i>&#160; so gew&#228;hlt ist, da&#223; er klein und handlich ist
@ -87752,8 +87724,8 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733590902929" ID="ID_1045639317" MODIFIED="1733590910632" TEXT="Implementierung overflow-Buckets">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1733590902929" ID="ID_1045639317" MODIFIED="1733868511337" TEXT="Implementierung overflow-Buckets">
<icon BUILTIN="pencil"/>
<node CREATED="1733765037437" ID="ID_1724101101" MODIFIED="1733765062311" TEXT="unterst&#xfc;tzte Interaktionen">
<node CREATED="1733765068881" ID="ID_523511672" MODIFIED="1733765084522" TEXT="ein default TurnoutSystem mit Grund-Ausstattung"/>
<node CREATED="1733765092674" ID="ID_1865816766" MODIFIED="1733765118024">
@ -87781,18 +87753,22 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
</node>
<node CREATED="1733766910569" ID="ID_462136727" MODIFIED="1733766922508" TEXT="&#x27f9; gebraucht wird">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733766926415" ID="ID_1686613162" MODIFIED="1733767188149" TEXT="Library f&#xfc;r heterogene verkn&#xfc;pfte Storage-Bl&#xf6;cke">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1733767199547" ID="ID_22701741" MODIFIED="1733767216844" TEXT="Template HeteroData"/>
<node COLOR="#435e98" CREATED="1733767218786" ID="ID_121902085" MODIFIED="1733774871018" TEXT="HeteroData_test"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733766926415" ID="ID_1686613162" MODIFIED="1733868469882" TEXT="Library f&#xfc;r heterogene verkn&#xfc;pfte Storage-Bl&#xf6;cke">
<icon BUILTIN="yes"/>
<node COLOR="#338800" CREATED="1733767199547" ID="ID_22701741" MODIFIED="1733868478977" TEXT="Template HeteroData">
<icon BUILTIN="button_ok"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733766989087" ID="ID_1930665408" MODIFIED="1733767188150" TEXT="typsicheres compiletime-Overlay f&#xfc;r diese">
<icon BUILTIN="flag-yellow"/>
<node COLOR="#338800" CREATED="1733767218786" ID="ID_121902085" MODIFIED="1733868478977" TEXT="HeteroData_test">
<icon BUILTIN="button_ok"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733766989087" ID="ID_1930665408" MODIFIED="1733868469882" TEXT="typsicheres compiletime-Overlay f&#xfc;r diese">
<icon BUILTIN="yes"/>
<node CREATED="1733767025290" ID="ID_741129447" MODIFIED="1733767039637" TEXT="daraus sollen die Accessoren erzeugbar sein"/>
<node CREATED="1733767103376" ID="ID_36453586" MODIFIED="1733767123425" TEXT="w&#xfc;nschenswert: factory-Funktionen f&#xfc;r bestimmte Storage-Bl&#xf6;cke"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733767147610" ID="ID_966052237" MODIFIED="1733767188150" TEXT="Zugriff auf einzelne Datenwerte per Accessor">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733767147610" ID="ID_966052237" MODIFIED="1733868469882" TEXT="Zugriff auf einzelne Datenwerte per Accessor">
<icon BUILTIN="yes"/>
<node CREATED="1733794253049" ID="ID_524032108" MODIFIED="1733794287860" TEXT="Grundlage: das C++ - Tuple-Protocol implementieren">
<icon BUILTIN="idea"/>
<node CREATED="1733794297502" ID="ID_351966457" MODIFIED="1733794342665" TEXT="std::get&lt;i&gt;, tuple_element, tuple_size"/>
@ -87872,7 +87848,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1733804575033" ID="ID_374529337" MODIFIED="1733804581760" TEXT="Konstruktur">
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1733804582990" ID="ID_234262358" MODIFIED="1733804620663" TEXT="puh ... komplex">
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1733804582990" ID="ID_234262358" MODIFIED="1733868402231" TEXT="puh ... komplex">
<icon BUILTIN="smily_bad"/>
<node CREATED="1733804622226" ID="ID_13001974" MODIFIED="1733804637342" TEXT="ich will zuerst Konstruktor-Typen konstruieren">
<node CREATED="1733804722045" ID="ID_1072077887" MODIFIED="1733804736615" TEXT="von diesem sollen bereits Accessoren abgenommen werden k&#xf6;nnen"/>
@ -87889,7 +87865,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1733804769854" ID="ID_148296974" MODIFIED="1733804802554" TEXT="Problem: diese Registrierung ist kniffelig">
<node BACKGROUND_COLOR="#d9be9d" COLOR="#8b175a" CREATED="1733804769854" ID="ID_148296974" MODIFIED="1733868443978" TEXT="Problem: diese Registrierung ist kniffelig">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1733804807001" ID="ID_1917086593" MODIFIED="1733804863683" TEXT="der StorageFrame is non-copyable">
<richcontent TYPE="NOTE"><html>
@ -88160,20 +88136,67 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="idea"/>
</node>
</node>
<node CREATED="1733855737147" ID="ID_1027151619" MODIFIED="1733855742750" TEXT="freistehender Konstruktor">
<node COLOR="#338800" CREATED="1733855737147" ID="ID_1027151619" MODIFIED="1733868366491" TEXT="freistehender Konstruktor">
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1733855744424" ID="ID_1254899343" MODIFIED="1733855771923" TEXT="Kurz-Notation einf&#xfc;hren: HeteroData&lt;X,Y,Z&gt;">
<icon BUILTIN="button_ok"/>
<node CREATED="1733855773870" ID="ID_803313039" MODIFIED="1733855792807" TEXT="damit sind dann die &#xbb;technischen&#xab; Spezialisierungen praktisch verborgen"/>
<node CREATED="1733855797419" ID="ID_1916700964" MODIFIED="1733855815052" TEXT="ein einfacher (unverkn&#xfc;pfter) HeteroData-Frame l&#xe4;&#xdf;t sich direkt anschreiben"/>
<node CREATED="1733855773870" ID="ID_803313039" MODIFIED="1733868561994" TEXT="damit sind dann die &#xbb;technischen&#xab; Spezialisierungen praktisch verborgen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...der Standard-Fall nimmt N... Template-Argumente und macht daraus ein Tupel
</p>
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733855818208" ID="ID_1630330383" MODIFIED="1733855837531" TEXT="diesem aber auch die Signatur eines Konstruktors geben">
<node CREATED="1733855797419" ID="ID_1916700964" MODIFIED="1733868602951" TEXT="ein einfacher (unverkn&#xfc;pfter) HeteroData-Frame l&#xe4;&#xdf;t sich direkt anschreiben">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...das ist dann die einzige Typ-Signatur, die der Benutzer selber schreiben mu&#223;: <font face="Monospaced" color="#2c1f5e">HeteroData&lt;X,Y,Z&gt;</font>
</p>
</body>
</html>
</richcontent>
</node>
</node>
<node COLOR="#338800" CREATED="1733855818208" ID="ID_1630330383" MODIFIED="1733868356780" TEXT="diesem aber auch die Signatur eines Konstruktors geben">
<icon BUILTIN="idea"/>
<node COLOR="#435e98" CREATED="1733855840409" ID="ID_551453590" MODIFIED="1733868349166" TEXT="damit steigt man einfach ein">
<icon BUILTIN="idea"/>
<node CREATED="1733855840409" ID="ID_551453590" MODIFIED="1733855863796" TEXT="damit steigt man einfach ein"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733855864730" ID="ID_1336801643" MODIFIED="1733855881097" TEXT="der direkte Konstruktor bleibt verborgen (oder default?)">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1733855885723" ID="ID_886647001" MODIFIED="1733855901574" TEXT="build sollte aber HeteroData erzeugen">
<node COLOR="#338800" CREATED="1733868331186" ID="ID_59006671" MODIFIED="1733868341015" TEXT="ist sogar default-konstruierbar">
<icon BUILTIN="button_ok"/>
</node>
<node COLOR="#338800" CREATED="1733855864730" ID="ID_1336801643" MODIFIED="1733868325562" TEXT="der direkte Konstruktor bleibt verborgen">
<icon BUILTIN="button_ok"/>
</node>
<node COLOR="#435e98" CREATED="1733855885723" ID="ID_886647001" MODIFIED="1733868313983" TEXT="build sollte aber HeteroData erzeugen">
<icon BUILTIN="broken-line"/>
<node CREATED="1733868645814" ID="ID_42325581" MODIFIED="1733868899501" TEXT="Konsequenz: std::tupel&lt;X,Y,Z&gt; wird verborgen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Das ist jetzt eine gewisse Asymetrie, die aber m.E. weniger wiegt, als der Vorteil, da&#223; der angeschriebene HeteroData-Typ auch tats&#228;chlich das ist, was f&#252;r das Front-End erzeugt wird &#8212; <i>notwendig</i>&#160;w&#228;re das &#252;berhaupt nicht, aber ohne Kenntnis der Definitionen w&#228;re ein solches Verhalten hochgradig verwirrend; immerhin gehe ich davon aus, da&#223; 90% der Leser nur den Standard-Fall sehen, und sich dann merken &#8222;das ist so eine Art Tupel...&#8220;
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1733868661716" ID="ID_1658275232" MODIFIED="1733868752404" TEXT="ist aber in der Praxis verschmerzbar">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
denn wir haben ja alle expliziten Accessor-Funktionen direkt auf dem Objekt nochmal definiert, und zudem wird das C++ Tuple-Protokoll implementiert
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1733868698535" ID="ID_1014714524" MODIFIED="1733868718664" TEXT="und gilt nicht f&#xfc;r die Chain-Bl&#xf6;cke"/>
</node>
</node>
</node>