Invocation: simplify and unify type decision logic
Now reaping the benefits of the ambitious refactorings done yesterday. - Only retaining the basic distinction of the four use cases - all further adaptation now directly based on the »lifted« types - can even add quite stringent compile-time sanity checks. Now the refactoring is on-par with the capabilities of the old downstream code, which, btw, could be retained in compilable (yet not working) state. But the new traits logic is already more capable and could accept tuples and arrays as well. Next major topic to address is to provide the foundation for parameter handling.
This commit is contained in:
parent
d5bbec6519
commit
990e4cbb68
3 changed files with 180 additions and 185 deletions
|
|
@ -270,6 +270,12 @@ namespace meta {
|
|||
using BAS::BAS;
|
||||
};
|
||||
|
||||
template<class BAS, typename TAG =void>
|
||||
struct Tagged
|
||||
: BAS
|
||||
{
|
||||
using BAS::BAS;
|
||||
};
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -106,21 +106,20 @@ namespace engine {
|
|||
namespace {// Introspection helpers....
|
||||
|
||||
using lib::meta::_Fun;
|
||||
using lib::meta::enable_if;
|
||||
using lib::meta::is_UnaryFun;
|
||||
using lib::meta::is_BinaryFun;
|
||||
using lib::meta::is_TernaryFun;
|
||||
using std::remove_reference_t;
|
||||
using lib::meta::enable_if;
|
||||
using lib::meta::is_Structured;
|
||||
using lib::meta::forEachIDX;
|
||||
using lib::meta::ElmTypes;
|
||||
using lib::meta::Tagged;
|
||||
using lib::meta::TySeq;
|
||||
using std::is_pointer;
|
||||
using std::is_reference;
|
||||
using std::remove_reference_t;
|
||||
using std::remove_pointer_t;
|
||||
using std::tuple_element_t;
|
||||
using std::tuple_size_v;
|
||||
using std::void_t;
|
||||
using std::__and_;
|
||||
using std::__not_;
|
||||
|
||||
|
|
@ -129,7 +128,6 @@ namespace engine {
|
|||
struct is_Value
|
||||
: __and_<__not_<is_pointer<V>>
|
||||
,__not_<is_reference<V>>
|
||||
,__not_<is_Structured<V>>
|
||||
,std::is_default_constructible<V>
|
||||
,std::is_copy_assignable<V>
|
||||
>
|
||||
|
|
@ -146,62 +144,19 @@ namespace engine {
|
|||
|
||||
|
||||
|
||||
template<class TUP, template<class> class COND>
|
||||
struct isAllElements
|
||||
{
|
||||
template<typename>
|
||||
struct AndAll;
|
||||
template<size_t...idx>
|
||||
struct AndAll<std::index_sequence<idx...>>
|
||||
{
|
||||
static constexpr bool value =
|
||||
__and_<COND<tuple_element_t<idx,TUP>> ...
|
||||
>::value;
|
||||
};
|
||||
using Elms = std::make_index_sequence<tuple_size_v<TUP>>;
|
||||
static constexpr bool value = AndAll<Elms>::value;
|
||||
};
|
||||
|
||||
template<class TUP, typename SEL = void>
|
||||
struct is_StructBuffs
|
||||
: std::false_type
|
||||
{ };
|
||||
template<class TUP>
|
||||
struct is_StructBuffs<TUP, enable_if<is_Structured<TUP>> >
|
||||
: isAllElements<TUP, is_Buffer>
|
||||
{ };
|
||||
|
||||
|
||||
template<class X, typename SEL = void>
|
||||
struct StructType
|
||||
{
|
||||
using Seq = TySeq<X>;
|
||||
using Tup = std::tuple<X>;
|
||||
};
|
||||
|
||||
template<class TUP>
|
||||
struct StructType<TUP, enable_if<is_Structured<TUP>> >
|
||||
{
|
||||
template<typename>
|
||||
struct AllZ;
|
||||
template<size_t...idx>
|
||||
struct AllZ<std::index_sequence<idx...>>
|
||||
{
|
||||
using Seq = TySeq<tuple_element_t<idx,TUP> ...>;
|
||||
};
|
||||
|
||||
using Elms = std::make_index_sequence<tuple_size_v<TUP>>;
|
||||
using Seq = typename AllZ<Elms>::Seq;
|
||||
using Tup = TUP;
|
||||
};
|
||||
|
||||
/** Helper to pick up the parameter dimensions from the processing function
|
||||
* @remark this is the rather simple yet common case that media processing
|
||||
* is done by a function, which takes an array of input and output
|
||||
* buffer pointers with a common type; this simple case is used
|
||||
* 7/2024 for prototyping and validate the design.
|
||||
* @tparam FUN a _function-like_ object, expected to accept two arguments,
|
||||
* which both are arrays of buffer pointers (input, output).
|
||||
/**
|
||||
* Trait template to analyse and adapt to the given processing function.
|
||||
* The detection logic encoded here attempts to figure out the meaning of
|
||||
* the function arguments by their arrangement and type. As a base rule,
|
||||
* the arguments are expected in the order: Parameters, Input, Output
|
||||
* - a single argument function can only be a data generator
|
||||
* - a binary function can either be a processor input -> output,
|
||||
* or accept parameters at «slot-0» and provide output at «slot-1»
|
||||
* - a ternary function is expected to accept Parameters, Input, Output.
|
||||
* @tparam FUN a _function-like_ object, expected to accept 1 - 3 arguments,
|
||||
* which all may be simple types, tuples or arrays.
|
||||
* @note »Buffers« are always accepted by pointer, which allows
|
||||
* to distinguish parameter and data «slots«
|
||||
*/
|
||||
template<class FUN>
|
||||
struct _ProcFun
|
||||
|
|
@ -212,49 +167,26 @@ namespace engine {
|
|||
|
||||
using Sig = typename _Fun<FUN>::Sig;
|
||||
|
||||
template<class SIG, size_t i>
|
||||
using _Arg = typename lib::meta::Pick<typename _Fun<SIG>::Args, i>::Type;
|
||||
template<size_t i>
|
||||
using _Arg = typename lib::meta::Pick<typename _Fun<Sig>::Args, i>::Type;
|
||||
|
||||
template<size_t i, template<class> class COND>
|
||||
using AllElements = typename ElmTypes<_Arg<i>>::template AndAll<COND>;
|
||||
|
||||
template<class ARG, typename SEL =void>
|
||||
struct _ArgTrait
|
||||
{
|
||||
static_assert(not sizeof(ARG), "processing function expected to take parameters, "
|
||||
"buffer-poiinters or tuples or arrays of these");
|
||||
};
|
||||
template<class PAR>
|
||||
struct _ArgTrait<PAR, enable_if<is_Value<PAR>>>
|
||||
{
|
||||
using Buff = PAR; ////////////////////////////////OOO not correct, remove this!
|
||||
using Args = TySeq<PAR>;
|
||||
enum{ SIZ = 1 };
|
||||
};
|
||||
template<class BUF>
|
||||
struct _ArgTrait<BUF*, enable_if<is_Buffer<BUF*>>>
|
||||
{
|
||||
using Buff = BUF;
|
||||
using Args = TySeq<BUF*>;
|
||||
enum{ SIZ = 1 };
|
||||
};
|
||||
// template<class TUP>
|
||||
// struct _ArgTrait<TUP, enable_if<is_StructBuffs<TUP>>>
|
||||
// {
|
||||
// using Args = typename StructType<TUP>::Seq;
|
||||
// enum{ SIZ = std::tuple_size_v<TUP> };
|
||||
// };
|
||||
template<class BUF, size_t N>
|
||||
struct _ArgTrait<std::array<BUF*,N>>
|
||||
{
|
||||
using Buff = BUF;
|
||||
using Args = TySeq<BUF>;///////////////////////////OOO Schmuh!!!
|
||||
enum{ SIZ = N };
|
||||
};
|
||||
|
||||
template<size_t i>
|
||||
static constexpr bool nonEmpty = ElmTypes<_Arg<i>>::SIZ;
|
||||
template<size_t i>
|
||||
static constexpr bool is_BuffSlot = AllElements<i, is_Buffer>();
|
||||
template<size_t i>
|
||||
static constexpr bool is_ParamSlot = AllElements<i, is_Value>();
|
||||
|
||||
/**
|
||||
* Detect use-case as indicated by the function signature
|
||||
*/
|
||||
template<class SIG, typename SEL =void>
|
||||
struct _Case
|
||||
{
|
||||
static_assert(not sizeof(SIG), "use case could not be determined from function stignature");
|
||||
static_assert (not sizeof(SIG), "use case could not be determined from function signature");
|
||||
};
|
||||
template<class SIG>
|
||||
struct _Case<SIG, enable_if<is_UnaryFun<SIG>>>
|
||||
|
|
@ -267,7 +199,7 @@ namespace engine {
|
|||
struct _Case<SIG, enable_if<is_BinaryFun<SIG>>>
|
||||
{
|
||||
enum{ SLOT_O = 1
|
||||
, SLOT_I = typename ElmTypes<_Arg<SIG,0>>::template AndAll<is_Buffer>()? 0 : 1
|
||||
, SLOT_I = (nonEmpty<0> and is_BuffSlot<0>)? 0 : 1
|
||||
};
|
||||
};
|
||||
template<class SIG>
|
||||
|
|
@ -278,19 +210,16 @@ namespace engine {
|
|||
};
|
||||
};
|
||||
|
||||
using SigI = _Arg<FUN,_Case<Sig>::SLOT_I>;
|
||||
using SigO = _Arg<FUN,_Case<Sig>::SLOT_O>;
|
||||
using SigP = _Arg<FUN, 0>;
|
||||
using ArgI = typename _ArgTrait<SigI>::Args;
|
||||
using ArgO = typename _ArgTrait<SigO>::Args;
|
||||
using ArgP = typename _ArgTrait<SigP>::Args;
|
||||
using SigI = _Arg<_Case<Sig>::SLOT_I>;
|
||||
using SigO = _Arg<_Case<Sig>::SLOT_O>;
|
||||
using SigP = _Arg< 0>;
|
||||
using ArgI = typename ElmTypes<SigI>::Seq;
|
||||
using ArgO = typename ElmTypes<SigO>::Seq;
|
||||
using ArgP = typename ElmTypes<SigP>::Seq;
|
||||
|
||||
using BuffI = typename _ArgTrait<SigI>::Buff;
|
||||
using BuffO = typename _ArgTrait<SigO>::Buff;
|
||||
|
||||
enum{ FAN_I = _ArgTrait<SigI>::SIZ
|
||||
, FAN_O = _ArgTrait<SigO>::SIZ
|
||||
, FAN_P = _ArgTrait<SigP>::SIZ
|
||||
enum{ FAN_I = ElmTypes<SigI>::SIZ
|
||||
, FAN_O = ElmTypes<SigO>::SIZ
|
||||
, FAN_P = ElmTypes<SigP>::SIZ
|
||||
, SLOT_I = _Case<Sig>::SLOT_I
|
||||
, SLOT_O = _Case<Sig>::SLOT_O
|
||||
, SLOT_P = 0
|
||||
|
|
@ -299,9 +228,22 @@ namespace engine {
|
|||
|
||||
static constexpr bool hasInput() { return SLOT_I != SLOT_O; }
|
||||
static constexpr bool hasParam() { return 0 < SLOT_I; }
|
||||
|
||||
/* ========== |consistency checks| ========== */
|
||||
static_assert (nonEmpty<SLOT_O> or nonEmpty<SLOT_I> or nonEmpty<SLOT_P>
|
||||
,"At least one slot of the function must accept data");
|
||||
static_assert (is_BuffSlot<SLOT_O>, "Output slot of the function must accept buffer pointers");
|
||||
static_assert (is_BuffSlot<SLOT_I>, "Input slot of the function must accept buffer pointers");
|
||||
static_assert (is_ParamSlot<SLOT_P> or not hasParam()
|
||||
,"Param slot must accept value data");
|
||||
|
||||
using BuffO = typename ArgO::List::Head;
|
||||
using BuffI = typename std::conditional<hasInput(), typename ArgI::List::Head, BuffO>::type; /////////////////////////TODO obsolete ... remove after switch
|
||||
};
|
||||
|
||||
|
||||
|
||||
/** FeedManifold building block: hold parameter data */
|
||||
template<class FUN>
|
||||
struct ParamStorage
|
||||
{
|
||||
|
|
@ -330,7 +272,7 @@ namespace engine {
|
|||
};
|
||||
|
||||
template<class X>
|
||||
struct NotProvided : lib::meta::NullType { };
|
||||
using NotProvided = Tagged<lib::meta::NullType, X>;
|
||||
|
||||
template<bool yes, class B>
|
||||
using Provide_if = std::conditional_t<yes, B, NotProvided<B>>;
|
||||
|
|
@ -394,10 +336,6 @@ namespace engine {
|
|||
: process{forward<INIT> (funSetup)...}
|
||||
{ }
|
||||
|
||||
|
||||
using TupI = typename StructType<ArgI>::Tup;
|
||||
using TupO = typename StructType<ArgO>::Tup;
|
||||
|
||||
template<size_t i, class ARG>
|
||||
auto&
|
||||
accessArg (ARG& arg)
|
||||
|
|
@ -408,6 +346,10 @@ namespace engine {
|
|||
return arg;
|
||||
}
|
||||
|
||||
using TupI = typename ElmTypes<ArgI>::Tup;
|
||||
using TupO = typename ElmTypes<ArgO>::Tup;
|
||||
|
||||
|
||||
void
|
||||
connect()
|
||||
{
|
||||
|
|
@ -418,11 +360,6 @@ namespace engine {
|
|||
using BuffI = remove_pointer_t<tuple_element_t<i, TupI>>;
|
||||
accessArg<i> (_F::inArgs) = & _F::inBuff[i].template accessAs<BuffI>();
|
||||
});
|
||||
// if constexpr (is_Structured<ArgI>())
|
||||
// for (uint i=0; i<FAN_I; ++i)
|
||||
// std::get<i> (_F::inArgs) = & _F::inBuff[i].template accessAs<BuffI>();
|
||||
// else
|
||||
// _F::inArgs = & _F::inBuff[0].template accessAs<BuffI>();
|
||||
}
|
||||
// always wire output buffer(s)
|
||||
{
|
||||
|
|
@ -431,11 +368,6 @@ namespace engine {
|
|||
using BuffO = remove_pointer_t<tuple_element_t<i, TupO>>;
|
||||
accessArg<i> (_F::outArgs) = & _F::outBuff[i].template accessAs<BuffO>();
|
||||
});
|
||||
// if constexpr (is_Structured<ArgO>())
|
||||
// for (uint i=0; i<FAN_O; ++i)
|
||||
// std::get<i> (_F::outArgs) = & _F::outBuff[i].template accessAs<BuffO>();
|
||||
// else
|
||||
// _F::outArgs = & _F::inBuff[0].template accessAs<BuffI>();
|
||||
}
|
||||
}
|
||||
|
||||
|
|
@ -465,8 +397,8 @@ namespace engine {
|
|||
struct SimpleFunctionInvocationAdapter
|
||||
: MAN
|
||||
{
|
||||
using BuffI = typename _ProcFun<FUN>::BuffI;
|
||||
using BuffO = typename _ProcFun<FUN>::BuffO;
|
||||
using BuffI = remove_pointer_t<typename _ProcFun<FUN>::BuffI>;
|
||||
using BuffO = remove_pointer_t<typename _ProcFun<FUN>::BuffO>;
|
||||
|
||||
enum{ N = MAN::STORAGE_SIZ
|
||||
, FAN_I = _ProcFun<FUN>::FAN_I
|
||||
|
|
@ -475,7 +407,8 @@ namespace engine {
|
|||
|
||||
static_assert(FAN_I <= N and FAN_O <= N);
|
||||
|
||||
using ArrayI = typename _ProcFun<FUN>::SigI;
|
||||
// using ArrayI = typename _ProcFun<FUN>::SigI;
|
||||
using ArrayI = typename _Fun<FUN>::Args::List::Head; ///////////////////TODO workaround for obsolete code, about to be removed
|
||||
using ArrayO = typename _ProcFun<FUN>::SigO;
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -25432,9 +25432,7 @@
|
|||
<node CREATED="1540505481022" ID="ID_1566437478" MODIFIED="1557498707226" TEXT="konkrete Widgets leben im DisplayFrame"/>
|
||||
<node CREATED="1540506987900" ID="ID_1173067540" MODIFIED="1557498707226">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
sub-Frame wird für <i>unsere</i> Kinder erzeugt
|
||||
|
|
@ -25776,9 +25774,7 @@
|
|||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1563467916708" ID="ID_568904515" MODIFIED="1576282358069" TEXT="klären: Kind-Widget managen/entfernen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
inwiefern gibt es Beschränkungen, wenn man ein Kind-Widget von einem Container entfernt?
|
||||
|
|
@ -26076,9 +26072,7 @@
|
|||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1576876029833" HGAP="57" ID="ID_893654405" MODIFIED="1576876116458" TEXT="klären: brauchen wir verschiedene Offsets per Typ" VSHIFT="3">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
also einen speziellen Offset für Clips und einen anderen speziellen Offset für Effekt-Marker?
|
||||
|
|
@ -26483,9 +26477,7 @@
|
|||
<icon BUILTIN="hourglass"/>
|
||||
<node COLOR="#435e98" CREATED="1678406932620" ID="ID_1079071766" MODIFIED="1678407138241" TEXT="Stand 3/23: geplant und angelegt">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Der Lösungsansatz ist entschieden...
|
||||
|
|
@ -27153,9 +27145,7 @@
|
|||
</node>
|
||||
<node CREATED="1677283111823" ID="ID_991289244" MODIFIED="1677283133867">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
⟹ ich kann das <b>Ergebnis nicht exportieren</b>
|
||||
|
|
@ -28370,9 +28360,7 @@
|
|||
<node CREATED="1553911798428" ID="ID_1946109008" MODIFIED="1557498707227" TEXT="es bietet nur teilweise die Aktionen eines Tangible"/>
|
||||
<node CREATED="1563466370058" ID="ID_863187721" MODIFIED="1576282358066" TEXT="automatisches Management könnte schwierig werden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
weil der Ruler ja in die Präsentation mit einbezogen ist
|
||||
|
|
@ -30375,9 +30363,7 @@
|
|||
</node>
|
||||
<node COLOR="#338800" CREATED="1566487379550" ID="ID_272047983" MODIFIED="1672875229852" TEXT="aber horizontal nur eine Minimal-Weite (100px)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Eigentlich benötigt wird das »Aufspreizen« nur in der vertikalen Dimension, damit sich die umschließende Box sinngemäß anpaßt; im Grunde würde es sogar genügen, nur das obere (Ruler)-ScrolledWindow zu dimensionieren, aber ich halte es für sicherer, vom eigentlichen innen liegenden Canvas aus aufzuspreizen, schon wegen der ggfs. dynamischen Dekoration für die Scrollbar. Als Kompromiß setze ich jetzt horizontal eine Mindest-Ausdehnung von 100px (das erscheint ohnehin sinnvoll für eine Timeline), aber in vertikaler Richtung setze ich einen size-Request auf die berechnete Canvas-Höhe
|
||||
|
|
@ -31400,9 +31386,7 @@
|
|||
<node CREATED="1562845842871" ID="ID_119822604" MODIFIED="1562845853198" TEXT="widget->get_path()"/>
|
||||
<node CREATED="1562854489102" ID="ID_1789577981" MODIFIED="1562854522386" TEXT="der erzeugte WidgetPath ist bereits eine Kopie">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
es ruft den Konstruktor WidgetPath(gobject, make_copy=true) auf
|
||||
|
|
@ -33862,9 +33846,7 @@
|
|||
<icon BUILTIN="broken-line"/>
|
||||
<node CREATED="1582498722221" ID="ID_90390359" MODIFIED="1582498771653" TEXT="naja... hab ihn jetzt als ViewHook ausgebaut">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
das war ein größeres Refactoring; dafür fällt dann die Lösung mit den rekursiv "eingehäkelten" Lambdas weg. Ist sicherlich besser so...
|
||||
|
|
@ -35218,9 +35200,7 @@
|
|||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1612471524505" ID="ID_1226213044" MODIFIED="1612471811699" TEXT="Widgets sollen nicht direkt mit dem Layout-Manager reden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Ich will nicht, daß der DisplayManager zu bedeutend wird, weil dann eine direkte Manipulation einzelner Widgets durch den DisplayManager als die "einfachste" und "natürlichste" Lösung erscheinen könnte. Dagegen wehre ich mich, weil es zu einer starken Kopplung führt.
|
||||
|
|
@ -36098,9 +36078,7 @@
|
|||
<node CREATED="1532797071961" ID="ID_965723020" MODIFIED="1532797076020" TEXT="hat init-Funktionen"/>
|
||||
<node CREATED="1532797076656" ID="ID_1083316138" MODIFIED="1576282358032">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
betrifft aber <b>nur Framework</b>-Funktionalität
|
||||
|
|
@ -36187,9 +36165,7 @@
|
|||
</node>
|
||||
<node CREATED="1533252898732" ID="ID_28088492" MODIFIED="1576282358030" TEXT="Gio::Application::signal_activate()">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
The signal_activate() signal is emitted on the primary instance
|
||||
|
|
@ -36597,9 +36573,7 @@
|
|||
</node>
|
||||
<node CREATED="1533311655519" ID="ID_946023766" MODIFIED="1561827465319">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
aber <i>wir</i> brauchen ein <b>laufendes</b> UI
|
||||
|
|
@ -37064,9 +37038,7 @@
|
|||
<node CREATED="1614391615637" FOLDED="true" ID="ID_1108644497" MODIFIED="1614391627843" TEXT="zur Event-Quelle wird eine Closure gebildet">
|
||||
<node CREATED="1614391628734" ID="ID_1671010257" MODIFIED="1614391663130" TEXT="und zwar für den konkreten Typ der Interaktion">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
also nicht generisch, sondern die spezifische Closure für z.B. den Fall drag-Clip
|
||||
|
|
@ -91737,7 +91709,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node COLOR="#435e98" CREATED="1734214199422" ID="ID_525858909" MODIFIED="1734299260472" TEXT="stellt sich wieder (zum x-ten Mal) die Frage nach dem Layout der FeedManifold">
|
||||
<arrowlink COLOR="#2e2c57" DESTINATION="ID_1045815708" ENDARROW="Default" ENDINCLINATION="-98;-400;" ID="Arrow_ID_639104343" STARTARROW="None" STARTINCLINATION="-367;14;"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1734299273886" ID="ID_1992832073" MODIFIED="1734299285393" TEXT="intern mehrstufig aufbauen">
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1734299273886" ID="ID_1992832073" MODIFIED="1734550631972" TEXT="intern mehrstufig aufgebaut">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1734299304455" ID="ID_286097173" MODIFIED="1734299376662" TEXT="Trait zur Fallunterscheidung">
|
||||
<arrowlink COLOR="#8e8fa7" DESTINATION="ID_978315882" ENDARROW="Default" ENDINCLINATION="52;169;" ID="Arrow_ID_793891080" STARTARROW="None" STARTINCLINATION="-331;-17;"/>
|
||||
|
|
@ -91830,7 +91802,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
<node CREATED="1734300344699" ID="ID_660526050" MODIFIED="1734300363029" TEXT="strukturierte Typen in einem zweiten Schritt hinzufügen">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734483863501" ID="ID_1884890390" MODIFIED="1734484068908" TEXT="sollte nochmal restukturieren....">
|
||||
<node COLOR="#435e98" CREATED="1734483863501" ID="ID_1884890390" MODIFIED="1734550617570" TEXT="sollte nochmal restukturieren....">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -91844,6 +91816,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node COLOR="#236883" CREATED="1734496443007" ID="ID_1580496045" LINK="#ID_1734731182" MODIFIED="1734496487271" TEXT="generisches Verarbeitungs-Schema: ElmTypes<TUP>">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node CREATED="1734550423852" ID="ID_1069917132" MODIFIED="1734550448603" TEXT="nur noch die Use-Case-Unterscheidung per Traits-Spezialisierung"/>
|
||||
<node CREATED="1734550451183" ID="ID_1408787596" MODIFIED="1734550469001" TEXT="sonstige Logik direkt auf Parameter-Eigenschafuten aufgebaut"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -91882,7 +91856,29 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1734458906909" ID="ID_53372671" MODIFIED="1734458916675" TEXT="später nochmal beurteilen">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
<node CREATED="1734550474791" ID="ID_384640118" MODIFIED="1734550506623" TEXT="vor allem: Downstream-Code muß damit richtig umgehen....">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node CREATED="1734547014206" ID="ID_1825901061" MODIFIED="1734547216709" TEXT="möglich unter einer Bedingung: Signatur muß reproduziert werden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
<u>Erläuterung</u>: egal wie die interne Logik abläuft, am Ende muß sie für jeden Slot <i>den Typ (kompatibel) ausweisen,</i> der initial für diese Stelle in der Signatur angegeben wurde
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<linktarget COLOR="#daf6fe" DESTINATION="ID_1825901061" ENDARROW="Default" ENDINCLINATION="-1280;54;" ID="Arrow_ID_1390781333" SOURCE="ID_573532514" STARTARROW="None" STARTINCLINATION="-446;-20;"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1734550521638" ID="ID_1993063494" MODIFIED="1734550551857" TEXT="Leer ⟹ kann kein Buffer-Argument sein">
|
||||
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
<node COLOR="#435e98" CREATED="1734550580870" ID="ID_896575935" MODIFIED="1734550605107" TEXT="Buffer ⟺ nur Pointer-Komponenten">
|
||||
<icon BUILTIN="info"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -91893,6 +91889,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node CREATED="1734299647835" ID="ID_300211802" MODIFIED="1734299682940" TEXT="versuche es direkt über die structured-bindings">
|
||||
<arrowlink COLOR="#685a75" DESTINATION="ID_822733161" ENDARROW="Default" ENDINCLINATION="15;31;" ID="Arrow_ID_1498083496" STARTARROW="None" STARTINCLINATION="83;5;"/>
|
||||
</node>
|
||||
<node CREATED="1734550645710" ID="ID_638858764" LINK="#ID_1086476352" MODIFIED="1734550671322" TEXT="Einzel-Argumente: in Tupel »heben«"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -92210,11 +92207,11 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1734398371276" ID="ID_1513818427" MODIFIED="1734474043348" TEXT="brauche forEach(IndexTuple)">
|
||||
<node COLOR="#435e98" CREATED="1734398371276" FOLDED="true" ID="ID_1513818427" MODIFIED="1734546135094" TEXT="brauche forEach(IndexTuple)">
|
||||
<linktarget COLOR="#4ab2e5" DESTINATION="ID_1513818427" ENDARROW="Default" ENDINCLINATION="-120;11;" ID="Arrow_ID_668892948" SOURCE="ID_81517996" STARTARROW="None" STARTINCLINATION="-103;-9;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1734399341087" ID="ID_763559603" MODIFIED="1734399361894" TEXT="sollte aber auch für frei stehenden Einzeltyp funktionieren"/>
|
||||
<node COLOR="#5b280f" CREATED="1734399363642" ID="ID_535610409" MODIFIED="1734471924041" TEXT="Verwende das gute alte InstantiateWithIndex aus generator.hpp">
|
||||
<node COLOR="#5b280f" CREATED="1734399363642" FOLDED="true" ID="ID_535610409" MODIFIED="1734546119828" TEXT="Verwende das gute alte InstantiateWithIndex aus generator.hpp">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1734399387338" ID="ID_683945175" MODIFIED="1734399397194" TEXT="ja ... die guten alten Loki-Listen"/>
|
||||
<node CREATED="1734399405485" ID="ID_676422515" MODIFIED="1734399426829" TEXT="brauche dazu dann nur die Typ-Sequenz für einen structuredType"/>
|
||||
|
|
@ -92222,9 +92219,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<icon BUILTIN="smily_bad"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734399930258" ID="ID_552320825" MODIFIED="1734471981106" TEXT="oder doch nur einen Index-Generator ⟶ λ">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#3d1981" CREATED="1734471983248" ID="ID_180764617" MODIFIED="1734475355476" TEXT="geht das überhaupt mit einem Lambda?">
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1734399930258" ID="ID_552320825" MODIFIED="1734546125548" TEXT="oder doch nur einen Index-Generator ⟶ λ">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#3d1981" CREATED="1734471983248" FOLDED="true" ID="ID_180764617" MODIFIED="1734475355476" TEXT="geht das überhaupt mit einem Lambda?">
|
||||
<font NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="help"/>
|
||||
<node COLOR="#5b280f" CREATED="1734472004853" ID="ID_1548338453" MODIFIED="1734472034734" TEXT="im Body wird der Index als constexpr gebraucht">
|
||||
|
|
@ -92378,17 +92375,17 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1734480964996" ID="ID_806319334" MODIFIED="1734480977083" TEXT="schrittweise auf komplexere Signaturen erweitern">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734483925269" ID="ID_1086476352" MODIFIED="1734484068908" TEXT="möglichst Fallunterscheidungen durch »Heben« vermeiden">
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1734483925269" ID="ID_1086476352" MODIFIED="1734546060607" TEXT="möglichst Fallunterscheidungen durch »Heben« vermeiden">
|
||||
<arrowlink COLOR="#c8022e" DESTINATION="ID_1884890390" ENDARROW="Default" ENDINCLINATION="-1263;97;" ID="Arrow_ID_232119446" STARTARROW="None" STARTINCLINATION="-517;-18;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1734483987277" ID="ID_1841429759" MODIFIED="1734483994879" TEXT="wir haben zu viele Einzelfälle"/>
|
||||
<node CREATED="1734483996540" ID="ID_249201624" MODIFIED="1734484013365" TEXT="es besteht die Gefahr, Typ-Struktur und Nutzen zu vermischen"/>
|
||||
<node CREATED="1734484014897" ID="ID_1533580969" MODIFIED="1734484112886" TEXT="Idee: alles per Iteration über StructType<T>">
|
||||
<arrowlink COLOR="#5583b2" DESTINATION="ID_1710377001" ENDARROW="Default" ENDINCLINATION="113;86;" ID="Arrow_ID_1043919586" STARTARROW="None" STARTINCLINATION="103;6;"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1734484966366" ID="ID_1734731182" MODIFIED="1734496372644" TEXT="Hilfsmittel zur Iteration über Element-Typen">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node COLOR="#338800" CREATED="1734484966366" ID="ID_1734731182" MODIFIED="1734546051435" TEXT="Hilfsmittel zur Iteration über Element-Typen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1734484982190" ID="ID_1667690583" MODIFIED="1734485007124">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
|
|
@ -92442,11 +92439,24 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1734496383891" ID="ID_352066932" MODIFIED="1734496422850" TEXT="damit sollte hoffentlich das _ProcFun-Traits-Template wesentlich einfacher werden....">
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1734496383891" ID="ID_352066932" MODIFIED="1734546010832" TEXT="damit wird das _ProcFun-Traits-Template wesentlich einfacher....">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node COLOR="#338800" CREATED="1734537123396" ID="ID_1099344573" MODIFIED="1734537142599" TEXT="Fehlsteuerung in der Use-Case-Erkennung jetzt einfach zu beheben">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1734545909195" ID="ID_655855847" MODIFIED="1734545946761" TEXT="Die spezielle Trait-Kaskade _Arg für jedes Argument kann komplett wegfallen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1734545948613" ID="ID_1474061827" MODIFIED="1734545969908" TEXT="die speziellen Metafunktionen is_StructBuffs können wegfallen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1734545972826" ID="ID_1185734846" MODIFIED="1734545994101" TEXT="mehrere dedizierte Iterations-Templates werden überflüssig">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1734550331943" ID="ID_1935947799" MODIFIED="1734550400425" TEXT="kann auch leere »slots» akzeptieren">
|
||||
<arrowlink COLOR="#83b5ac" DESTINATION="ID_573532514" ENDARROW="Default" ENDINCLINATION="178;-18;" ID="Arrow_ID_109400658" STARTARROW="None" STARTINCLINATION="-110;8;"/>
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1734535852731" ID="ID_745699305" MODIFIED="1734537109150" TEXT="Test: Einzel-Buffer IN ⟶ OUT">
|
||||
|
|
@ -92457,6 +92467,52 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<icon BUILTIN="broken-line"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1734546191477" ID="ID_700906161" MODIFIED="1734546209411" TEXT="Leere Signatur-Slots">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1734546212121" ID="ID_847430872" MODIFIED="1734546226854" TEXT="z.B. im bestehenden NodeLinkage_test">
|
||||
<node CREATED="1734546252740" ID="ID_368698478" MODIFIED="1734546283608">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
void dummyOp (<font color="#d80f0f"><b>NoArg</b></font> in, <b>SoloArg</b> out)
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<font NAME="SansSerif" SIZE="11"/>
|
||||
</node>
|
||||
<node CREATED="1734546333505" ID="ID_1369045625" MODIFIED="1734546509505" TEXT="der erste Slot kann nicht klassifiziert werden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
rein logisch läßt sich das nicht lösen — die Entscheidung beruht dann auf einer willkürlichen Konvention; im Moment habe ich fesgelegt: »das können keine Buffer sein«
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1734546349095" ID="ID_1864083410" MODIFIED="1734546372125" TEXT="per Default wird er ein Param-Slot"/>
|
||||
</node>
|
||||
<node CREATED="1734546907140" ID="ID_1830073767" MODIFIED="1734546915372" TEXT="sinnvolle Logik">
|
||||
<node CREATED="1734546807275" ID="ID_590391415" MODIFIED="1734546967843" TEXT="im Zweifelsfall ⟶ Parameter (defensiver Ansatz)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
denn für einen Parameter-Slot muß weniger getan werden; im Zweifelsfall muß er nur default-konstruiert werden — und es wird dann halt auch kein Param-Funktor dazu aufgerufen
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1734546970587" ID="ID_573532514" MODIFIED="1734550387114" TEXT="aber wichtig ist: für den Aufruf muß jeder Slot »seinen« Typ wieder bekommen">
|
||||
<arrowlink COLOR="#daf6fe" DESTINATION="ID_1825901061" ENDARROW="Default" ENDINCLINATION="-1280;54;" ID="Arrow_ID_1390781333" STARTARROW="None" STARTINCLINATION="-446;-20;"/>
|
||||
<linktarget COLOR="#83b5ac" DESTINATION="ID_573532514" ENDARROW="Default" ENDINCLINATION="178;-18;" ID="Arrow_ID_109400658" SOURCE="ID_1935947799" STARTARROW="None" STARTINCLINATION="-110;8;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1734133400400" ID="ID_1364724277" MODIFIED="1734141875620" TEXT="zusätzlichen Funktor für die Parameter akzeptieren">
|
||||
|
|
|
|||
Loading…
Reference in a new issue