ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Parameters: reorganise TypeHandler interface

Browse source 
The original design (based on Alexandrescu) is more elegant,
but has the downside to bloat the VTable size due to the mix-in
arrangement used to generate the interface.

The ongoing design has revealed a tight constraint on element size
for the parameters; thus the change to a linearised inheritance chain.

The overall purpose remains the same: the ability to generate a
double-dispatch type conversion, so that the actual value type of the
parameter can be treated as an implicit implementation detail.
This commit is contained in:
Fischlurch 2026-09-01 19:47:31 +02:00
parent 764185eb85
commit 0ebb2afc15
4 changed files with 131 additions and 69 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

56
src/lib/par/domain.hpp
View file

@ -35,7 +35,6 @@
#include "lib/meta/typelist.hpp"
//#include "lib/meta/typelist-util.hpp"
#include "lib/meta/generator.hpp"
#include "lib/par/provision.hpp"
#include "lib/meta/trait.hpp"
@ -54,52 +53,32 @@ namespace par {
using std::numeric_limits;
/* ===== Type Handler Interface for generic parameter value access ===== */
template<typename X>
constexpr inline ValBuff&
asValBuff (X& something)
{
void* rawMem{& something};
return * static_cast<ValBuff*> (rawMem);
}
class HandlerBase
: public Provision
{
public:
void extractAs();
void conform();
};
template<typename X>
constexpr inline ValBuff const&
asValBuff (X const& something)
{
void const * rawMem{& something};
return * static_cast<ValBuff const *> (rawMem);
}
template<typename X>
constexpr inline X&
asValue (ValBuff& storage)
{
void* rawMem{& storage};
return * static_cast<X*> (rawMem);
}
template<typename X>
constexpr inline X const&
asValue (ValBuff const& storage)
{
void const * rawMem{& storage};
return * static_cast<X const *> (rawMem);
}
template<typename X>
template<typename X, class PAR>
class TypeHandler
: public PAR
{
public:
virtual void extractAs (X& targetVal, ValBuff const& valBuff) =0;
virtual void conform (ValBuff& targetBuff, X const& srcVal) =0;
using PAR::extractAs;
using PAR::conform;
};
// using lib::meta::typeseq;
/**
* Fixed collection of elementary types supported in parameters
*/
using BaseTypes = meta::Types<int
,int64_t
,uint
@ -109,7 +88,7 @@ namespace par {
,bool
>;
/** build a generic visitor interface for all types in list */
using TypeHandlerInterface = meta::InstantiateForEach<BaseTypes::List, TypeHandler, Provision>;
using TypeHandlerInterface = meta::InstantiateChained<BaseTypes::List, TypeHandler, HandlerBase>;
/**
@ -302,8 +281,7 @@ _Pragma("GCC diagnostic pop")
inline void
BaseDomain<V>::transferTo (ValBuff const& source, Domain& targetDomain, ValBuff& target)
{
TypeHandler<V>& typeHandler{targetDomain};
typeHandler.conform (target, asValue<V> (source));
targetDomain.conform (target, asValue<V> (source));
targetDomain.applyLimit (target);
}

42
src/lib/par/provision.hpp
View file

@ -33,16 +33,54 @@ namespace par {
using time::Time;
/** Marker for an opaque value buffer with
* undisclosed size and content type */
struct ValBuff { /*placeholder*/ };
template<typename X>
constexpr inline ValBuff&
asValBuff (X& something)
{
void* rawMem{& something};
return * static_cast<ValBuff*> (rawMem);
}
template<typename X>
constexpr inline ValBuff const&
asValBuff (X const& something)
{
void const * rawMem{& something};
return * static_cast<ValBuff const *> (rawMem);
}
template<typename X>
constexpr inline X&
asValue (ValBuff& storage)
{
void* rawMem{& storage};
return * static_cast<X*> (rawMem);
}
template<typename X>
constexpr inline X const&
asValue (ValBuff const& storage)
{
void const * rawMem{& storage};
return * static_cast<X const *> (rawMem);
}
/**
* Interface: access to a parameter's value, to adjust or evaluate automation.
* Conceptually, the value is decomposed into a _base value_ and possibly a
* time-controlled adjustment (automation). The base value can be retrieved
* and assigned, while the current time-based value is the result of evaluation.
* Any parameter value is associated to a ParamType that defines the underlying
* value domain and possibly a scale with range limits and metric constraints.
* Any parameter value is implicitly associated with a Type that defines the
* underlying [value domain](\ref Domain) and possibly a \ref Scale that
* defines range limits and metric constraints.
* @remark the value access and manipulation works _backwards_ from an implicit
* value that is conceptually located _within_ this provision towards
* an ValBuff for external access. The reason for this indirect

22
tests/lib/par/parameter-domain-test.cpp
View file

@ -184,7 +184,9 @@ namespace test{
verify_valueAccess()
{
BaseDomain<int> domInt;
SHOW_EXPR(sizeof(BaseDomain<int>)) ///////////////////////////////////////TODO this should be only one »slot«, but is actually quite large, due to using multiple inheritance in the Domain interface. /////OOO fix that!
CHECK (sizeof(BaseDomain<int>) <= sizeof(void*)); // only the VTable
// use the generic interface for access...
Domain& dom{domInt};
int val = 1 + rani (1000);
@ -193,21 +195,18 @@ SHOW_EXPR(sizeof(BaseDomain<int>)) ///////////////////////////////////////TODO t
uint target1{0};
CHECK (not target1);
TypeHandler<uint>& hu{dom};
hu.extractAs (target1, src);
dom.extractAs (target1, src);
CHECK (target1 == uint(val));
float target2{0};
TypeHandler<float>& hf{dom};
hf.extractAs (target2, src);
dom.extractAs (target2, src);
CHECK (target2 == float(val));
// value clamped to target domain...
val = _MIN<int>;
uint64_t target3{55};
TypeHandler<uint64_t>& hu64{dom};
hu64.extractAs (target3, src);
dom.extractAs (target3, src);
CHECK (target3 == _MIN<uint64_t>);
}
@ -229,20 +228,17 @@ SHOW_EXPR(sizeof(BaseDomain<int>)) ///////////////////////////////////////TODO t
ValBuff& target = asValBuff (val_in_buff);
uint src1 = 1 + rani (1000);
TypeHandler<uint>& hu{dom};
hu.conform (target, src1);
dom.conform (target, src1);
CHECK (val_in_buff == int(src1));
double src2 = ranRange (1,100);
CHECK (1 <= src2 and src2 < 100);
TypeHandler<double>& hd{dom};
hd.conform (target, src2);
dom.conform (target, src2);
CHECK (val_in_buff == int(floor (src2)));
// value clamped to target domain...
auto mini = _MIN<int64_t>;
TypeHandler<int64_t>& h64{dom};
h64.conform (target, mini);
dom.conform (target, mini);
CHECK (val_in_buff == _MIN<int>);
}

78
wiki/thinkPad.ichthyo.mm
View file

@ -82995,7 +82995,7 @@
<node BACKGROUND_COLOR="#c8c0b6" CREATED="1784489444352" ID="ID_1412623970" MODIFIED="1784489521150" TEXT="doch! das funktioniert weiterhin">
<icon BUILTIN="idea"/>
</node>
<node CREATED="1784489483382" ID="ID_617432070" MODIFIED="1787695360380">
<node CREATED="1784489483382" ID="ID_617432070" MODIFIED="1788284693233">
<richcontent TYPE="NODE"><html>
<head/>
<body>
@ -83030,7 +83030,7 @@
</p>
</body>
</html></richcontent>
<linktarget COLOR="#ffe99c" DESTINATION="ID_617432070" ENDARROW="Default" ENDINCLINATION="236;9;" ID="Arrow_ID_1412212027" SOURCE="ID_711986937" STARTARROW="None" STARTINCLINATION="236;9;"/>
<linktarget COLOR="#ffe99c" DESTINATION="ID_617432070" ENDARROW="Default" ENDINCLINATION="184;7;" ID="Arrow_ID_1412212027" SOURCE="ID_711986937" STARTARROW="None" STARTINCLINATION="162;6;"/>
<linktarget COLOR="#fe8953" DESTINATION="ID_617432070" ENDARROW="Default" ENDINCLINATION="368;0;" ID="Arrow_ID_1535827259" SOURCE="ID_1219008003" STARTARROW="None" STARTINCLINATION="463;38;"/>
</node>
</node>
@ -83090,11 +83090,11 @@
<node COLOR="#352c84" CREATED="1784491298401" ID="ID_427305032" MODIFIED="1784491298401" TEXT="Fazit {generiertes Multi-TypeHandler-OO-Interface}">
<font BOLD="true" NAME="SansSerif" SIZE="12"/>
<icon BUILTIN="forward"/>
<node CREATED="1784491360016" ID="ID_711986937" MODIFIED="1784491537887" TEXT="das Original-Baumuster von Alexandrescu ist immer noch die beste L&#xf6;sung">
<arrowlink COLOR="#ffe99c" DESTINATION="ID_617432070" ENDARROW="Default" ENDINCLINATION="236;9;" ID="Arrow_ID_1412212027" STARTARROW="None" STARTINCLINATION="236;9;"/>
<node CREATED="1784491360016" ID="ID_711986937" MODIFIED="1788284693233" TEXT="das Original-Baumuster von Alexandrescu ist immer noch eine elegante L&#xf6;sung">
<arrowlink COLOR="#ffe99c" DESTINATION="ID_617432070" ENDARROW="Default" ENDINCLINATION="184;7;" ID="Arrow_ID_1412212027" STARTARROW="None" STARTINCLINATION="162;6;"/>
</node>
<node CREATED="1784491373675" ID="ID_1952132123" MODIFIED="1784491392120" TEXT="die Implementierung per Chain braucht keine Sichtbarkeit der anderen Overloads"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1784491392987" ID="ID_1626670078" MODIFIED="1784491428279" TEXT="auf Ambiguit&#xe4;ten in den Typ-Signaturen achten">
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1784491392987" ID="ID_1626670078" MODIFIED="1788284654454" TEXT="auf Ambiguit&#xe4;ten in den Typ-Signaturen achten">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
@ -83103,6 +83103,7 @@
</p>
</body>
</html></richcontent>
<linktarget COLOR="#474ebe" DESTINATION="ID_1626670078" ENDARROW="Default" ENDINCLINATION="317;19;" ID="Arrow_ID_1833189754" SOURCE="ID_35862304" STARTARROW="None" STARTINCLINATION="396;16;"/>
<icon BUILTIN="clanbomber"/>
</node>
</node>
@ -83117,7 +83118,7 @@
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1788209315295" ID="ID_279904556" MODIFIED="1788210268056" TEXT="VTables bl&#xe4;hen sich auf">
<node COLOR="#435e98" CREATED="1788209315295" ID="ID_279904556" MODIFIED="1788284583155" TEXT="VTables bl&#xe4;hen sich auf">
<icon BUILTIN="broken-line"/>
<node CREATED="1788209326125" ID="ID_1531181426" MODIFIED="1788209343878" TEXT="Mix-in &#x27f9; schlie&#xdf;t jedes Sub-Objekt komplett mit ein">
<node CREATED="1788210282924" ID="ID_1520344652" MODIFIED="1788210493326" TEXT="zwar gibt C++ keinerlei Garantien zum Daten-Layout (au&#xdf;er f&#xfc;r PODs)">
@ -83164,10 +83165,23 @@
</html></richcontent>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1788211053578" ID="ID_1121107125" MODIFIED="1788214912904" TEXT="Also &#x27f9; mu&#xdf; doch umstellen auf eine lineare Kette &#x2014; auch f&#xfc;r die Interfaces">
<linktarget COLOR="#f91755" DESTINATION="ID_1121107125" ENDARROW="Default" ENDINCLINATION="-1456;53;" ID="Arrow_ID_1757832686" SOURCE="ID_1738529643" STARTARROW="None" STARTINCLINATION="-304;11;"/>
<node COLOR="#435e98" CREATED="1788211053578" ID="ID_1121107125" MODIFIED="1788284625243" TEXT="Also &#x27f9; mu&#xdf; doch umstellen auf eine lineare Kette &#x2014; auch f&#xfc;r die Interfaces">
<linktarget COLOR="#a81651" DESTINATION="ID_1121107125" ENDARROW="Default" ENDINCLINATION="-1456;53;" ID="Arrow_ID_1757832686" SOURCE="ID_1738529643" STARTARROW="None" STARTINCLINATION="-297;13;"/>
<icon BUILTIN="yes"/>
</node>
<node COLOR="#0c5669" CREATED="1788284754476" ID="ID_653345776" MODIFIED="1788284851663" TEXT="nun Assert im Test auf Gr&#xf6;&#xdf;e des Basis-Interfaces">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...was nicht komplett durch den C++ - Standard gedeckt ist, jedoch aufgrund der Alignment-Contstraints und der Pflicht zur zero-overhead-Implementierung praktisch immer gegeben sein d&#252;rfte
</p>
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1788284591681" ID="ID_35862304" MODIFIED="1788284660301" TEXT="Fazit: etwas kniffligere Definition &#x2014; aber weniger Ambituit&#xe4;ts-Probleme">
<arrowlink COLOR="#474ebe" DESTINATION="ID_1626670078" ENDARROW="Default" ENDINCLINATION="317;19;" ID="Arrow_ID_1833189754" STARTARROW="None" STARTINCLINATION="396;16;"/>
</node>
</node>
</node>
</node>
@ -84335,7 +84349,7 @@
</p>
</body>
</html></richcontent>
<arrowlink COLOR="#f91755" DESTINATION="ID_1121107125" ENDARROW="Default" ENDINCLINATION="-1456;53;" ID="Arrow_ID_1757832686" STARTARROW="None" STARTINCLINATION="-304;11;"/>
<arrowlink COLOR="#a81651" DESTINATION="ID_1121107125" ENDARROW="Default" ENDINCLINATION="-1456;53;" ID="Arrow_ID_1757832686" STARTARROW="None" STARTINCLINATION="-297;13;"/>
</node>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1788207092440" ID="ID_1489003663" MODIFIED="1788214784231" TEXT="Typ und BaseDomain werden zum Problem">
<icon BUILTIN="messagebox_warning"/>
@ -84354,8 +84368,16 @@
<icon BUILTIN="messagebox_warning"/>
</node>
</node>
<node CREATED="1788207233069" ID="ID_403725711" MODIFIED="1788207254569" TEXT="aber die konkrete Scale mu&#xdf; darauf aufbauen (da sie Werte beschr&#xe4;nkt)"/>
<node CREATED="1788215170120" ID="ID_1317810371" MODIFIED="1788215194280" TEXT="Typ mu&#xdf; konkret sein, schlie&#xdf;t BaseDomain ein und verweist auf Scale"/>
<node CREATED="1788207233069" ID="ID_403725711" MODIFIED="1788207254569" TEXT="aber die konkrete Scale mu&#xdf; darauf aufbauen (da sie Werte beschr&#xe4;nkt)">
<node CREATED="1788277709450" HGAP="60" ID="ID_1575437557" MODIFIED="1788277762386" TEXT="&#x201e;aufbauen&#x201c; hei&#xdf;t nicht zwangsl&#xe4;ufig auch &#x201e;erweitern&#x201c;" VSHIFT="1">
<icon BUILTIN="idea"/>
</node>
</node>
<node CREATED="1788215170120" ID="ID_1317810371" MODIFIED="1788215194280" TEXT="Typ mu&#xdf; konkret sein, schlie&#xdf;t BaseDomain ein und verweist auf Scale">
<node CREATED="1788279901620" HGAP="78" ID="ID_1647252878" MODIFIED="1788279934225" TEXT="umbenennen in &#x27fc; TypedEntity" VSHIFT="1">
<icon BUILTIN="yes"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1788215427662" ID="ID_214321685" MODIFIED="1788217785702" TEXT="Das Povision-Interface mu&#xdf; anders angeordnet werden">
<linktarget COLOR="#ff001d" DESTINATION="ID_214321685" ENDARROW="Default" ENDINCLINATION="4;-14;" ID="Arrow_ID_1991058182" SOURCE="ID_1569730697" STARTARROW="None" STARTINCLINATION="-120;4;"/>
@ -84371,7 +84393,16 @@
</html></richcontent>
<node CREATED="1788215575560" ID="ID_690071422" MODIFIED="1788215606429" TEXT="das ist das front-End"/>
<node CREATED="1788215613679" ID="ID_200801579" MODIFIED="1788215624951" TEXT="somit wird hier auch eine Interface-Kette eingemischt"/>
<node CREATED="1788215708763" ID="ID_907924223" MODIFIED="1788215727096" TEXT="oder man w&#xfc;rde Zugang zu einer Provision bieten"/>
<node CREATED="1788215708763" ID="ID_907924223" MODIFIED="1788277831015" TEXT="oder man w&#xfc;rde Zugang zu einer Provision bieten">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
bedeutet, es gibt eine Methode um eine Provision&amp; zu bekommen, welche konsequenterweise dann &#252;ber das Implementierungs-Interface erreichbar sein mu&#223; (da wir uns auf eine einfache Vererbungskette einschr&#228;nken m&#252;ssen)
</p>
</body>
</html></richcontent>
</node>
</node>
<node CREATED="1788215737795" ID="ID_516807030" MODIFIED="1788215749277" TEXT="Provision wird damit ein eigenst&#xe4;ndiges Interface">
<node CREATED="1788215750841" ID="ID_374789197" MODIFIED="1788215911279" TEXT="sie ist nur implizit getypt">
@ -84402,12 +84433,12 @@
</html></richcontent>
</node>
</node>
<node CREATED="1788221594093" ID="ID_579519208" MODIFIED="1788221708229" TEXT="es mu&#xdf; aber per default als NOP implementiert sein">
<node CREATED="1788221594093" ID="ID_579519208" MODIFIED="1788279294776" TEXT="es mu&#xdf; aber per default als NOP implementiert sein">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...sonst wird es schwierig mit dem Zusammenstellen der Interface-Kette; tats&#228;chlich lassen sich alle f&#252;r dieses Interface vorgesehenen Operationen &#187;leer&#171; Implementieren &#8212; es passiert dann einfach gar nichts, keine Zuweisung, keine Verbindung
...sonst wird es schwierig mit dem Zusammenstellen der Interface-Kette; tats&#228;chlich lassen sich alle f&#252;r dieses Interface vorgesehenen Operationen &#187;leer&#171; Implementieren&#160;&#8212; es passiert dann einfach gar nichts, keine Zuweisung, keine Verbindung &#8212; was inhaltlich-logisch sogar korrekt ist, ein NICHTS-Parameter...
</p>
</body>
</html></richcontent>
@ -84421,6 +84452,25 @@
<node CREATED="1788222544142" ID="ID_1947215779" MODIFIED="1788222568288" TEXT="es wird per PolymorphicValue auf das Parameter-Objekt exponiert"/>
<node CREATED="1788222571539" ID="ID_1256386409" MODIFIED="1788222603029" TEXT="die ganze konkrete Implementierung setzt darauf auf (und bleibt damit opaque, und variierbar)"/>
</node>
<node CREATED="1788279465992" ID="ID_511934631" MODIFIED="1788279480380" TEXT="Insgesamt entsteht hier eine Konkretisierungs-Kette">
<node CREATED="1788279482831" ID="ID_1252818882" MODIFIED="1788279536466" TEXT="wir gehen vom Kontrakt zum Service">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
es handelt sich dabei durchgehend um Abstraktionen, wobei sich jedoch der Charakter der Abstraktion &#228;ndert von einer Zusicherung zu etwas, auf dem wir konkret aufbauen k&#246;nnen
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1788279539424" ID="ID_1639736337" MODIFIED="1788279543780" TEXT="Bedeutung der Stufen">
<node CREATED="1788279549319" ID="ID_120197629" MODIFIED="1788279575207" TEXT="Provision: die Grundidee eines Parameters wie hier konzeptionalisiert"/>
<node CREATED="1788279579772" ID="ID_1387667429" MODIFIED="1788279619787" TEXT="Domain: Zusicherung einer Typ-konformen Handhabung"/>
<node CREATED="1788279649921" ID="ID_829245549" MODIFIED="1788279664995" TEXT="BaseDomain: Festlegung der Eigenschaften der Datenbasis"/>
<node CREATED="1788279667230" ID="ID_1645392786" MODIFIED="1788279840724" TEXT="TypedEntity: Konformit&#xe4;t und Darstelluns-F&#xe4;higkeiten"/>
<node CREATED="1788280039452" ID="ID_1355845527" MODIFIED="1788280070438" TEXT="Disposition: der komplette Parameter-Service"/>
</node>
</node>
</node>
<node CREATED="1788134884746" ID="ID_195532610" MODIFIED="1788134888546" TEXT="Builder-Notation">
<node CREATED="1788134893182" ID="ID_1219540786" MODIFIED="1788134948392" TEXT="naheliegend: statischer Einsteieg vom Parameter-Frontend">