Invocation: define entrance point for the first data tuple
Decision to use the generic case as short-hand for the first data block, and thus ''hide the more technical Loki-List specialisations'' With that, I'm finally able to write the first test case...
This commit is contained in:
parent
56bf5ecc8e
commit
510c39091d
3 changed files with 61 additions and 36 deletions
|
|
@ -73,11 +73,8 @@ namespace lib {
|
|||
|
||||
/**
|
||||
*/
|
||||
template<class SPEC>
|
||||
class HeteroData
|
||||
{
|
||||
/////////////////////////OOO do we need this as marker for an unspecified front-end?
|
||||
};
|
||||
template<typename...DATA>
|
||||
class HeteroData;
|
||||
|
||||
template<class TAIL, typename...DATA>
|
||||
class HeteroData<meta::Node<StorageFrame<DATA...>,TAIL>>
|
||||
|
|
@ -99,6 +96,9 @@ namespace lib {
|
|||
return * reinterpret_cast<_Tail*> (Frame::next);
|
||||
}
|
||||
|
||||
template<typename...XX>
|
||||
friend class HeteroData; ///< allow chained types to use recursive type definitions
|
||||
|
||||
public:
|
||||
static constexpr size_t
|
||||
size()
|
||||
|
|
@ -142,8 +142,8 @@ namespace lib {
|
|||
using ChainType = meta::Append<meta::Node<Frame,TAIL>,NewFrame>;
|
||||
|
||||
template<typename...INIT>
|
||||
NewFrame
|
||||
operator() (INIT&& ...initArgs)
|
||||
static NewFrame
|
||||
build (INIT&& ...initArgs)
|
||||
{
|
||||
return {initArgs ...};
|
||||
}
|
||||
|
|
@ -165,18 +165,26 @@ namespace lib {
|
|||
public:
|
||||
static size_t constexpr size() { return 0; }
|
||||
|
||||
template<typename...DATA>
|
||||
struct Constructor
|
||||
template<size_t>
|
||||
using Elm_t = void;
|
||||
};
|
||||
|
||||
template<typename...DATA>
|
||||
class HeteroData
|
||||
: public HeteroData<meta::Node<StorageFrame<DATA...>, meta::NullType>>
|
||||
{
|
||||
using _Front = HeteroData<meta::Node<StorageFrame<DATA...>, meta::NullType>>;
|
||||
|
||||
public:
|
||||
using NewFrame = typename _Front::Frame;
|
||||
using ChainType = _Front;
|
||||
|
||||
template<typename...INIT>
|
||||
static NewFrame
|
||||
build (INIT&& ...initArgs)
|
||||
{
|
||||
using Chain = HeteroData<meta::Node<StorageFrame<DATA...>, meta::NullType>>;
|
||||
|
||||
template<typename...INIT>
|
||||
typename Chain::Frame
|
||||
operator() (INIT&& ...initArgs)
|
||||
{
|
||||
return {initArgs ...};
|
||||
}
|
||||
};
|
||||
return {initArgs ...};
|
||||
}
|
||||
};
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -18,12 +18,16 @@
|
|||
|
||||
#include "lib/test/run.hpp"
|
||||
#include "lib/hetero-data.hpp"
|
||||
#include "lib/meta/trait.hpp"
|
||||
#include "lib/test/diagnostic-output.hpp"/////////////////TODO
|
||||
|
||||
|
||||
|
||||
namespace lib {
|
||||
namespace test{
|
||||
|
||||
using meta::is_Subclass;
|
||||
|
||||
namespace { // probe victims
|
||||
|
||||
}//(End) test data
|
||||
|
|
@ -54,7 +58,12 @@ namespace test{
|
|||
void
|
||||
checkSingleKill ()
|
||||
{
|
||||
using Block1 = HeteroData<uint,double>;
|
||||
CHECK ((is_Subclass<Block1, std::tuple<uint,double>>()));
|
||||
|
||||
auto b1 = Block1::build (42, 1.61803);
|
||||
SHOW_EXPR(b1)
|
||||
CHECK (1.61803 == std::get<1> (b1));
|
||||
}
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -87855,8 +87855,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
Konkret ist das Problem, daß die Fold-Expression von meinem Compiler nicht als constexpr akzeptiert wird (weil man ja über die Fold-Expression einen Index inkrementiert). Möglicherweise würde das dann mit C++20 gehen?
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1733851787845" ID="ID_412406851" MODIFIED="1733851807217" TEXT="dann doch lieber eine einfache rekursive Lösung mit constexpr-if">
|
||||
<icon BUILTIN="yes"/>
|
||||
|
|
@ -87963,8 +87962,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
...diese ist ein Funktor, der von <i>gans woanders</i> stammt — nämlich von dem Builder aus dem High-Level-Model gewrappt, z.B. Auswertung einer Bézier-Kurve
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1733835046313" ID="ID_1292820259" MODIFIED="1733835132658" TEXT="die so erzeugten Parameter gehen in den Tupel-Konstruktor"/>
|
||||
<node CREATED="1733835133813" ID="ID_838878251" MODIFIED="1733835167301" TEXT="und das Resultat ist ein Datenobjekt">
|
||||
|
|
@ -87984,8 +87982,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
gestern habe ich mich furchbar geplagt, weil ich fest davon überzeugt war, daß dieses Anhängen im Konstruktor untergebracht werden muß
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#fffde1" DESTINATION="ID_1456102629" ENDARROW="Default" ENDINCLINATION="-241;13;" ID="Arrow_ID_1934239160" SOURCE="ID_1185565269" STARTARROW="None" STARTINCLINATION="-98;366;"/>
|
||||
<icon BUILTIN="ksmiletris"/>
|
||||
</node>
|
||||
|
|
@ -88054,8 +88051,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
Konsequenz: die Funktion, die <i>an den Chain anhängt,</i> muß die Längen-Info haben
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1733836986637" ID="ID_1879337196" MODIFIED="1733836996216" TEXT="ist das realisierbar?">
|
||||
<icon BUILTIN="help"/>
|
||||
|
|
@ -88067,8 +88063,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
insofern ist es ja schon attraktiv, mit dem Konstruktor-Funktor zu »zaubern«
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1733837063899" ID="ID_655018902" MODIFIED="1733837103119" TEXT="man könnte diese Info im Typ des Datenrecords unterbringen">
|
||||
<node CREATED="1733837116469" ID="ID_135729693" MODIFIED="1733837151564" TEXT="der Record wäre damit sozusagen zwangsweise an eine bestimmte Position im Chain gebunden"/>
|
||||
|
|
@ -88083,8 +88078,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
an einen Chain der richtigen Länge angehängt werden
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1733837104583" ID="ID_690949960" MODIFIED="1733837225743" TEXT="oh — das klingt gut">
|
||||
<icon BUILTIN="idea"/>
|
||||
|
|
@ -88101,8 +88095,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
Daten-Record wird markiert mit Template-Parameter <b><font color="#5d0b0b" face="Monospaced"><u>prefixLen</u></font></b>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1733837352697" ID="ID_1648354214" MODIFIED="1733837394585" TEXT="der bekommt eine Methode linkInto(HeteroData&)"/>
|
||||
<node CREATED="1733837395855" ID="ID_458018454" MODIFIED="1733837635994" TEXT="und delegiert in eine Funktion attachAtEnd(len)">
|
||||
|
|
@ -88113,8 +88106,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
die kann unmittelbar die Länge prüfen und dann an's Ende gehen und den Pointer dort setzen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -88136,8 +88128,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
weil es ja für den gesamten Teilbaum relevant ist
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1733841390686" ID="ID_419650667" MODIFIED="1733841410639" TEXT="der initiale Einstiegspunkt liegt im Default-Turnout-System"/>
|
||||
<node CREATED="1733841412235" ID="ID_106981990" MODIFIED="1733841470551" TEXT="aber auch dieses selber braucht schon einen Konstruktor-Typ als Hilfsmittel"/>
|
||||
|
|
@ -88169,6 +88160,23 @@ 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="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>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733855818208" ID="ID_1630330383" MODIFIED="1733855837531" TEXT="diesem aber auch die Signatur eines Konstruktors geben">
|
||||
<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">
|
||||
<icon BUILTIN="broken-line"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1733767161520" ID="ID_1853669534" MODIFIED="1733767188150" TEXT="Standard-Definition für TurnoutSystem auf dieser Basis">
|
||||
|
|
|
|||
Loading…
Reference in a new issue