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:
parent
510c39091d
commit
eed0f55f83
3 changed files with 110 additions and 71 deletions
|
|
@ -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 ...};
|
||||
|
|
|
|||
|
|
@ -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>());
|
||||
}
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -21845,9 +21845,7 @@
|
|||
</node>
|
||||
<node CREATED="1666476057276" ID="ID_1151114899" MODIFIED="1666476103630" TEXT="es sind also zwei getrennte (strukturell änliche Fä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äre, die Diff-Verben mitzulesen.
|
||||
|
|
@ -22945,9 +22941,7 @@
|
|||
</node>
|
||||
<node CREATED="1480778768988" ID="ID_1385067618" MODIFIED="1576282358078" TEXT="und das alles nur für....">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
einen Fall, der <i>praktisch nie</i> 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ängen garnicht direkt damit zusammen, sondern wurden getriggert durch den "unorthodoxen" Gebrauch des PtrDerefIter
|
||||
|
|
@ -26744,9 +26734,7 @@
|
|||
<node CREATED="1540747533463" ID="ID_1845120165" MODIFIED="1557498707227" TEXT="dann wä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ß 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ösung: virtueller widget-Path „fischt“ im gegebenen CSS-Kontext">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
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 @@
|
|||
<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> von Gio::Application
|
||||
|
|
@ -38803,9 +38785,7 @@
|
|||
<node CREATED="1618677381682" ID="ID_1297330759" MODIFIED="1618677391341" TEXT="GTK führt hier einen "gdouble" ein"/>
|
||||
<node CREATED="1618677393499" ID="ID_1949606460" MODIFIED="1618677453343" TEXT="Grund ist Portabilitä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ü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ürde der fluiden Verwendung schaden"/>
|
||||
<node CREATED="1667156513645" ID="ID_1002330972" MODIFIED="1667156696839" TEXT="mäßig gefä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 (≙ 23sec)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...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 <i>DEFAULT_CANVAS</i>  so gewählt ist, daß er klein und handlich ist
|
||||
|
|
@ -87752,8 +87724,8 @@ Date:   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ü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:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
<node CREATED="1733766910569" ID="ID_462136727" MODIFIED="1733766922508" TEXT="⟹ gebraucht wird">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733766926415" ID="ID_1686613162" MODIFIED="1733767188149" TEXT="Library für heterogene verknüpfte Storage-Blö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ür heterogene verknüpfte Storage-Blö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ü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ü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ünschenswert: factory-Funktionen für bestimmte Storage-Blö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<i>, tuple_element, tuple_size"/>
|
||||
|
|
@ -87872,7 +87848,7 @@ Date:   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önnen"/>
|
||||
|
|
@ -87889,7 +87865,7 @@ Date:   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:   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ühren: HeteroData<X,Y,Z>">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1733855773870" ID="ID_803313039" MODIFIED="1733855792807" TEXT="damit sind dann die »technischen« Spezialisierungen praktisch verborgen"/>
|
||||
<node CREATED="1733855797419" ID="ID_1916700964" MODIFIED="1733855815052" TEXT="ein einfacher (unverknüpfter) HeteroData-Frame läßt sich direkt anschreiben"/>
|
||||
<node CREATED="1733855773870" ID="ID_803313039" MODIFIED="1733868561994" TEXT="damit sind dann die »technischen« 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üpfter) HeteroData-Frame läßt sich direkt anschreiben">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...das ist dann die einzige Typ-Signatur, die der Benutzer selber schreiben muß: <font face="Monospaced" color="#2c1f5e">HeteroData<X,Y,Z></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<X,Y,Z> 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ß der angeschriebene HeteroData-Typ auch tatsächlich das ist, was für das Front-End erzeugt wird — <i>notwendig</i> 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...“
|
||||
</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ür die Chain-Blöcke"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
|
|||
Loading…
Reference in a new issue