TreeExplorer: draft ability to remould the filter
The intention is to switch from the itertools-based filter to the filter available in the TreeExplorer framework. Thus "basically" we just need to copy the solution over, since both are conceptually equivalent. However...... :-( The TreeExplorer framework is designed to be way more generic and accepts basically everything as argument and tries to adapt apropriately. This means we have to use a lot of intricate boilerplate code, just to get the same effect that was possible in Itertools with a simple and elegant in-place lambda assignment
This commit is contained in:
parent
757258fb3a
commit
94da0f627f
3 changed files with 197 additions and 2 deletions
|
|
@ -526,7 +526,7 @@ namespace lib {
|
|||
|
||||
template<typename ARG>
|
||||
Res
|
||||
operator() (ARG& arg)
|
||||
operator() (ARG& arg) const
|
||||
{
|
||||
auto accessArg = ArgAccessor<ARG>::build();
|
||||
|
||||
|
|
@ -910,6 +910,31 @@ namespace lib {
|
|||
pullFilter();
|
||||
}
|
||||
|
||||
|
||||
/* === Remould the Filter condition underway === */
|
||||
|
||||
template<typename COND>
|
||||
void
|
||||
andFilter (COND conjunctiveClause)
|
||||
{
|
||||
using _ChainTraits = _BoundFunctor<COND,SRC>;
|
||||
using Res = typename _ChainTraits::Res;
|
||||
static_assert(std::is_constructible<bool, Res>::value, "Chained Functor must be a predicate");
|
||||
|
||||
using ChainPredicate = typename _ChainTraits::Functor;
|
||||
|
||||
FilterPredicate& firstClause = this->predicate_;
|
||||
ChainPredicate chainClause{forward<COND> (conjunctiveClause)};
|
||||
|
||||
|
||||
predicate_ = FilterPredicate{[firstClause, chainClause] (auto val)
|
||||
{
|
||||
return firstClause(val)
|
||||
and chainClause(val);
|
||||
} };
|
||||
pullFilter();
|
||||
}
|
||||
|
||||
private:
|
||||
SRC&
|
||||
srcIter() const
|
||||
|
|
|
|||
|
|
@ -276,6 +276,7 @@ namespace test{
|
|||
verify_combinedExpandTransform();
|
||||
verify_scheduledExpansion();
|
||||
verify_FilterIterator();
|
||||
verify_FilterChanges();
|
||||
verify_asIterSource();
|
||||
verify_IterSource();
|
||||
|
||||
|
|
@ -847,6 +848,28 @@ namespace test{
|
|||
|
||||
|
||||
|
||||
/** @test the filter layer can be re-configured on the fly */
|
||||
void
|
||||
verify_FilterChanges()
|
||||
{
|
||||
auto seq = treeExplore(CountDown{20})
|
||||
.filter([](uint){ return true; });
|
||||
|
||||
auto takeEve = [](uint i){ return i%2 == 0; };
|
||||
auto takeTrd = [](uint i){ return i%3 == 0; };
|
||||
|
||||
CHECK (20 == *seq);
|
||||
++seq;
|
||||
CHECK (19 == *seq);
|
||||
CHECK (19 == *seq);
|
||||
|
||||
seq.andFilter (takeEve);
|
||||
CHECK (18 == *seq);
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
/** @test package the resulting Iterator as automatically managed,
|
||||
* polymorphic opaque entity implementing the IterSource interface.
|
||||
* The builder operations on TreeExplorer each generate a distinct, implementation
|
||||
|
|
|
|||
|
|
@ -30840,7 +30840,8 @@
|
|||
<icon BUILTIN="help"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1535893707036" ID="ID_257876647" MODIFIED="1535893716894" TEXT="Aufgabe: Filter erweiterbar machen">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1535893707036" ID="ID_257876647" MODIFIED="1535899964941" TEXT="Aufgabe: Filter erweiterbar machen">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1535893718194" ID="ID_872370459" MODIFIED="1535893743691" TEXT="analog zum Filter in den Itertools"/>
|
||||
<node CREATED="1535893752174" ID="ID_386073545" MODIFIED="1535893777011" TEXT="ggfs diesen dort ablösen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
|
|
@ -30855,6 +30856,152 @@
|
|||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1535903530421" ID="ID_384303362" MODIFIED="1535903535289" TEXT="Aua">
|
||||
<icon BUILTIN="smily_bad"/>
|
||||
<node CREATED="1535903536820" ID="ID_1343418651" MODIFIED="1535903541919" TEXT="das wird komplex..."/>
|
||||
<node CREATED="1535903542556" ID="ID_1721469481" MODIFIED="1535903551375" TEXT="der Filter-Layer ist hochgradig generisch"/>
|
||||
<node CREATED="1535904105560" ID="ID_1560346116" MODIFIED="1535904127224" TEXT="muß auch das Chain-Argument durch die Funktor-Traits schleusen"/>
|
||||
<node CREATED="1535904128524" ID="ID_1238934363" MODIFIED="1535904140074" TEXT="Code wird grausam">
|
||||
<icon BUILTIN="smiley-angry"/>
|
||||
<node CREATED="1535904143098" ID="ID_646600775" MODIFIED="1535904152669" TEXT="funktioniert, aber gewaltig aufgebläht"/>
|
||||
<node CREATED="1535904153353" ID="ID_616241221" MODIFIED="1535904403272" TEXT="ganz nah am Segfault vorbei">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...und das hängt an einem hauchdünnen Faden,
|
||||
</p>
|
||||
<p>
|
||||
und ist subtil bis zum geht nicht mehr....
|
||||
</p>
|
||||
<p>
|
||||
|
||||
</p>
|
||||
<p>
|
||||
Wenn man das Lambda einfach per [=] schreibt, und das Feld this->predicate_ verwendet,
|
||||
</p>
|
||||
<p>
|
||||
dann wird this gecaptured (und das ist effektiv per Referenz). Wenn ich dann den
|
||||
</p>
|
||||
<p>
|
||||
konstruierten Funktor an this->predicate_ zuweise, haben wir eine Endlos-Rekursion.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
</p>
|
||||
<p>
|
||||
Lösung: man muß im lokalen Frame eine Referenz auf this->predicate definieren und binden.
|
||||
</p>
|
||||
<p>
|
||||
Diese wird dann per Value gecaptured, was die gewünschte Kopie bewirkt.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1535904168943" ID="ID_1936705749" MODIFIED="1535904249188" TEXT="eine unnötige Kopie">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...muß den Chain-Funktor aus dem Template-Argument erzeugen,
|
||||
</p>
|
||||
<p>
|
||||
und ihn dann in die per-Value-Closure des erzeugten neuen Lambda binden (=Kopie).
|
||||
</p>
|
||||
<p>
|
||||
|
||||
</p>
|
||||
<p>
|
||||
Erst ab C++17 kann man Lambda-Captures pre move machen
|
||||
</p>
|
||||
<p>
|
||||
(und auch dafür ist die Syntax grausam)
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1535904461720" ID="ID_317840110" MODIFIED="1535904468474" TEXT="will ich das wirklich.....?">
|
||||
<node CREATED="1535904470670" ID="ID_160594644" MODIFIED="1535904516890" TEXT="natürlich nicht">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...es soll bloß einfach funktionieren!!!!!!!!!!!
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="ksmiletris"/>
|
||||
</node>
|
||||
<node CREATED="1535906366785" ID="ID_1488862884" MODIFIED="1535906388442" TEXT="Komplexität entsteht aus der Flexibilität der Argumente">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node CREATED="1535904517824" ID="ID_305725479" MODIFIED="1535904857801" TEXT="stattdessen Itertools-Filter verwenden?">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
keine gute Idee.
|
||||
</p>
|
||||
<p>
|
||||
Dann verwenden wir im einen Funktor-Framework eine Filter-Komponente
|
||||
</p>
|
||||
<p>
|
||||
aus dem anderen Framework, obwohl es direkt hier auch eine Filter-Komponente gäbe.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
</p>
|
||||
<p>
|
||||
Außerdem habe ich immer noch die Hoffnung, irgendwann mal
|
||||
</p>
|
||||
<p>
|
||||
die Itertools komplett durch den TreeExplorer ablösen zu können
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
</node>
|
||||
<node CREATED="1535906261464" ID="ID_1343076549" MODIFIED="1535906264259" TEXT="Auswege">
|
||||
<node CREATED="1535906265911" ID="ID_442265155" MODIFIED="1535906279633" TEXT="speziellen Filter-Layer nur hierfür">
|
||||
<node CREATED="1535906327782" ID="ID_1903350743" MODIFIED="1535906334769" TEXT="letztlich nur Code-Kosmetik"/>
|
||||
</node>
|
||||
<node CREATED="1535906283948" ID="ID_367978731" MODIFIED="1535906294727" TEXT="Chain-Filter-Bau in HIlfsfunktion">
|
||||
<node CREATED="1535906394646" ID="ID_296637778" MODIFIED="1535906399057" TEXT="wünschenswert"/>
|
||||
<node CREATED="1535906399621" ID="ID_1487063274" MODIFIED="1535906407632" TEXT="nicht klar, ob überhaupt möglich"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1535899873112" ID="ID_1460874987" MODIFIED="1535899882165" TEXT="Unit-Test (replizieren)">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1535899922873" ID="ID_1971708144" MODIFIED="1535899950863" TEXT="bestehende Aufrufe konsolidieren">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...so daß es nur noch wenige Zugangs-Punkte zum unterliegenden Iterator gibt
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1535893799799" ID="ID_706866636" MODIFIED="1535893804419" TEXT="Auswertungs-Stack">
|
||||
|
|
|
|||
Loading…
Reference in a new issue