benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Library: elaborate SeveralBuilder operations

Browse source 
Consider what (not) to support.
Notably I decided ''not to support'' moving out of an iterator,
since doing so would contradict the fundamental assumptions of
the »Lumiera Forward Iterator« Concept.

Start verifying some variations of element placement,
still focussing on the simple cases
This commit is contained in:
Fischlurch 2024-06-11 18:23:48 +02:00
parent 773325f1bc
commit 1a76fb46f3
10 changed files with 269 additions and 181 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
src/lib/iter-adapter.hpp
View file

@ -72,8 +72,8 @@
** be expected from any such iterator. These rules are similar to STL's
** "forward iterator", with the addition of an bool check to detect
** iteration end. The latter is inspired by the \c hasNext() function
** found in many current languages supporting iterators. In a similar
** vein (inspired from functional programming), we deliberately don't
** found in many current languages supporting iterators. However, by
** inspiration from functional programming, we deliberately do not
** support the various extended iterator concepts from STL and boost
** (random access iterators, output iterators, arithmetics, difference
** between iterators and the like). According to this concept,
@ -90,6 +90,13 @@
** _dereferenced_ to yield the "current" value.
** - moreover, iterators may be incremented until exhaustion.
**
** Conceptually, a Lumiera Iterator represents a lazy stream of calculations
** rather than a target value considered to be »within« a container. And while
** the result is deliberately _always exposed as a reference,_ to keep the
** door open for special-case manipulations, for the typical usage it is
** _discouraged_ to assume anything about the source, beyond the limited
** access to some transient state as exposed during active iteration.
**
** @see iter-adapter-test.cpp
** @see itertools.hpp
** @see IterSource (completely opaque iterator)
@ -326,7 +333,7 @@ namespace lib {
* right into the iterator. Contrast this to IterAdapter, which refers to a managing
* container behind the scenes. Here, all of the state is assumed to live in the
* custom type embedded into this iterator, accessed and manipulated through
* a set of free functions, picked up through ADL.
* a dedicated _iteration control API_ exposed as member functions.
*
* \par Assumptions when building iterators based on IterStateWrapper
* There is a custom state representation type ST.

47
src/lib/several-builder.hpp
View file

@ -168,7 +168,7 @@ namespace lib {
REQUIRE (bucket);
using ElmAlloT = typename AlloT::template rebind_traits<E>;
auto elmAllo = adaptAllocator<E>();
E* loc = & bucket->subscript (idx);
E* loc = reinterpret_cast<E*> (& bucket->subscript (idx));
ElmAlloT::construct (elmAllo, loc, forward<ARGS> (args)...);
ENSURE (loc);
return *loc;
@ -185,7 +185,10 @@ namespace lib {
using ElmAlloT = typename AlloT::template rebind_traits<E>;
auto elmAllo = adaptAllocator<E>();
for (size_t idx=0; idx<cnt; ++idx)
ElmAlloT::destroy (elmAllo, & bucket->subscript(idx));
{
E* elm = reinterpret_cast<E*> (& bucket->subscript (idx));
ElmAlloT::destroy (elmAllo, elm);
}
}
size_t storageBytes = Bucket::requiredStorage (bucket->buffSiz);
std::byte* loc = reinterpret_cast<std::byte*> (bucket);
@ -295,6 +298,34 @@ namespace lib {
return move(*this);
}
template<class X>
SeveralBuilder&&
appendAll (std::initializer_list<X> ili)
{
using Val = typename meta::Strip<X>::TypeReferred;
for (Val const& x : ili)
emplaceNewElm<Val> (x);
return move(*this);
}
template<typename...ARGS>
SeveralBuilder&&
fillElm (size_t cntNew, ARGS&& ...args)
{
for ( ; 0<cntNew; --cntNew)
emplaceNewElm<I> (forward<ARGS> (args)...);
return move(*this);
}
template<class TY, typename...ARGS>
SeveralBuilder&&
emplace (ARGS&& ...args)
{
using Val = typename meta::RefTraits<TY>::Value;
emplaceNewElm<Val> (forward<ARGS> (args)...);
return move(*this);
}
/**
* Terminal Builder: complete and lock the collection contents.
@ -307,18 +338,22 @@ namespace lib {
return move (*this);
}
size_t size() const { return Coll::size(); }
bool empty() const { return Coll::empty();}
private:
template<class IT>
void
emplaceCopy (IT& dataSrc)
{
using Val = std::remove_cv_t<typename IT::value_type>;
emplaceElm<Val> (*dataSrc);
using Val = typename IT::value_type;
emplaceNewElm<Val> (*dataSrc);
}
template<class TY, typename...ARGS>
void
emplaceElm (ARGS&& ...args)
emplaceNewElm (ARGS&& ...args)
{
// mark when target type is not trivially movable
probeMoveCapability<TY>();
@ -330,7 +365,7 @@ namespace lib {
% util::typeStr<TY>() % reqSiz<TY>() % Coll::spread()};
// ensure sufficient storage or verify the ability to re-allocate
if (not (Coll::hasReserve(reqSiz<TY>())
if (not (Coll::empty() or Coll::hasReserve(reqSiz<TY>())
or POL::canExpand(reqSiz<TY>())
or canDynGrow()))
throw err::Invalid{_Fmt{"Unable to accommodate further element of type %s "}

6
src/lib/test/test-coll.hpp
View file

@ -44,7 +44,7 @@ namespace test{
template<class VEC>
inline VEC
getTestSeq_int(const uint NUM_ELMS)
getTestSeq_int (const uint NUM_ELMS)
{
VEC vec;
for (uint i=0; i<NUM_ELMS; ++i)
@ -63,7 +63,7 @@ namespace test{
template<class MAP>
inline MAP
getTestMap_int(const uint NUM_ELMS)
getTestMap_int (const uint NUM_ELMS)
{
MAP map;
for (uint i=0; i<NUM_ELMS; ++i)
@ -74,7 +74,7 @@ namespace test{
template<class MUMAP>
inline MUMAP
getTestMultiMap_int(const uint NUM_ELMS)
getTestMultiMap_int (const uint NUM_ELMS)
{
MUMAP map;
for (uint i=0; i<NUM_ELMS; ++i)

6
src/lib/test/testdummy.hpp
View file

@ -63,7 +63,7 @@ namespace test{
}
Dummy ()
: val_(1 + (rand() % 100000000))
: val_(1 + (rand() % 100'000'000))
{ init(); }
Dummy (int v)
@ -87,7 +87,7 @@ namespace test{
/** a dummy API operation */
virtual long
acc (int i)
calc (int i)
{
return val_+i;
}
@ -118,7 +118,7 @@ namespace test{
}
static void
activateCtorFailure(bool indeed =true)
activateCtorFailure (bool indeed =true)
{
_throw_in_ctor = indeed;
}

2
tests/library/linked-elements-test.cpp
View file

@ -251,7 +251,7 @@ namespace test{
while (ii)
{
CHECK (check == ii->getVal());
CHECK (check == ii->acc(+5) - 5);
CHECK (check == ii->calc(+5) - 5);
--check;
++ii;
}

32
tests/library/scoped-collection-test.cpp
View file

@ -55,12 +55,12 @@ namespace test{
* @param i when zero, the trigger value will be revealed
*/
virtual long
acc (int i)
calc (int i)
{
if (!i)
return getVal() + trigger_;
else
return Dummy::acc(i);
return Dummy::calc(i);
}
public:
@ -164,7 +164,7 @@ namespace test{
while (ii)
{
CHECK (check == ii->getVal());
CHECK (check == ii->acc(+5) - 5);
CHECK (check == ii->calc(+5) - 5);
++check;
++ii;
}
@ -262,11 +262,11 @@ namespace test{
CHECK (sum + rr == Dummy::checksum());
CHECK (d0.acc(11) == coll[0].getVal() + 11 );
CHECK (d1.acc(22) == rr + 22);
CHECK (d2.acc(33) == rr + 33);
CHECK (d2.acc(0) == rr + (rr+1) ); // SubDummy's special implementation of the acc()-function
// returns the trigger value, when the argument is zero
CHECK (d0.calc(11) == coll[0].getVal() + 11 );
CHECK (d1.calc(22) == rr + 22);
CHECK (d2.calc(33) == rr + 33);
CHECK (d2.calc(0) == rr + (rr+1) ); // SubDummy's special implementation of the acc()-function
// returns the trigger value, when the argument is zero
coll.clear();
coll.emplace<SubDummy> (11,22);
@ -277,10 +277,10 @@ namespace test{
// NOTE DANGEROUS:
// The previously obtained references just point into the object storage.
// Thus we're now accessing a different object, even a different type!
CHECK (d0.acc(0) == 11 + 22);
CHECK (d0.calc(0) == 11 + 22);
// The others even point into obsoleted storage holding zombie objects
CHECK (d1.acc(44) == rr + 44);
CHECK (d1.calc(44) == rr + 44);
}
CHECK (0 == Dummy::checksum());
@ -317,12 +317,12 @@ namespace test{
CHECK (6 == coll.size());
CHECK (0 != Dummy::checksum());
CHECK (coll[0].acc(0) == 0 + rr);
CHECK (coll[1].acc(0) == 1 + rr + trigger);
CHECK (coll[2].acc(0) == 2 + rr);
CHECK (coll[3].acc(0) == 3 + rr + trigger);
CHECK (coll[4].acc(0) == 4 + rr);
CHECK (coll[5].acc(0) == 5 + rr + trigger);
CHECK (coll[0].calc(0) == 0 + rr);
CHECK (coll[1].calc(0) == 1 + rr + trigger);
CHECK (coll[2].calc(0) == 2 + rr);
CHECK (coll[3].calc(0) == 3 + rr + trigger);
CHECK (coll[4].calc(0) == 4 + rr);
CHECK (coll[5].calc(0) == 5 + rr + trigger);
// what does this check prove?
// - the container was indeed populated with DubDummy objects
// since the overridden version of Dummy::acc() did run and

10
tests/library/scoped-holder-test.cpp
View file

@ -100,13 +100,13 @@ namespace test{
CHECK (0 < Dummy::checksum());
CHECK ( &(*holder));
CHECK (holder->acc(2) == 2 + Dummy::checksum());
CHECK (holder->calc(2) == 2 + Dummy::checksum());
Dummy *rawP = holder.get();
CHECK (rawP);
CHECK (holder);
CHECK (rawP == &(*holder));
CHECK (rawP->acc(-5) == holder->acc(-5));
CHECK (rawP->calc(-5) == holder->calc(-5));
TRACE (test, "holder at %p", &holder);
TRACE (test, "object at %p", holder.get() );
@ -214,7 +214,7 @@ namespace test{
HO & contained = maph[i];
CHECK (!contained);
} // 100 holder objects created by sideeffect
// ..... without creating any contained object!
// ..... without creating any contained object!
CHECK (0 == Dummy::checksum());
CHECK (!isnil (maph));
CHECK (100==maph.size());
@ -223,13 +223,13 @@ namespace test{
{
create_contained_object (maph[i]);
CHECK (maph[i]);
CHECK (0 < maph[i]->acc(12));
CHECK (0 < maph[i]->calc(12));
}
CHECK (100==maph.size());
CHECK (0 != Dummy::checksum());
long value55 = maph[55]->acc(0);
long value55 = maph[55]->calc(0);
long currSum = Dummy::checksum();
CHECK (1 == maph.erase(55));

2
tests/library/scoped-holder-transfer-test.cpp
View file

@ -147,7 +147,7 @@ namespace test {
CHECK (rawP);
CHECK (table[5]);
CHECK (rawP == &(*table[5]));
CHECK (rawP->acc(-555) == table[5]->acc(-555));
CHECK (rawP->calc(-555) == table[5]->calc(-555));
}
CHECK (0 == Dummy::checksum());
}

51
tests/library/several-builder-test.cpp
View file

@ -28,6 +28,7 @@
#include "lib/test/run.hpp"
#include "lib/test/testdummy.hpp"
#include "lib/test/test-coll.hpp"
#include "lib/test/test-helper.hpp"
#include "lib/test/diagnostic-output.hpp"////////////////TODO
#include "lib/iter-explorer.hpp"
@ -44,6 +45,8 @@ using std::vector;
using std::rand;
using lib::explore;
using util::isLimited;
using util::isnil;
using util::join;
@ -68,7 +71,7 @@ namespace test{
public:
Num (uint seed=i)
: Dummy{seed}
: Dummy(seed)
{
ext_.fill(seed);
setVal ((i+1)*seed);
@ -79,7 +82,7 @@ namespace test{
}
long
acc (int ii) override
calc (int ii) override
{
return i+ii + explore(ext_).resultSum();
}
@ -110,7 +113,7 @@ namespace test{
simpleUsage();
check_Builder();
check_ErrorHandling();
check_ElementAccess();
check_ElementStorage();
check_CustomAllocator();
}
@ -131,11 +134,47 @@ namespace test{
/** @test TODO various ways to build an populate the container
* @todo WIP 6/24 🔁 define ⟶ implement
* @todo WIP 6/24 🔁 define ⟶ ✔ implement
*/
void
check_Builder()
{
SeveralBuilder<Dummy> builder;
CHECK (isnil (builder));
builder.emplace<Num<3>>()
.emplace<Num<2>>(1);
CHECK (2 == builder.size());
builder.fillElm(2);
CHECK (4 == builder.size());
builder.fillElm(3, 5);
CHECK (7 == builder.size());
Several<Dummy> elms = builder.build();
CHECK ( isnil(builder));
CHECK (not isnil(elms));
CHECK (7 == elms.size());
SHOW_EXPR(elms[0])
SHOW_EXPR(elms[0].getVal())
CHECK (elms[0].getVal() == (3+1)*3); // indeed a Num<3> with default-seed ≡ 3
SHOW_EXPR(elms[0].calc(1))
CHECK (elms[0].calc(1) == 3 + 1 + (3+3+3)); // indeed called the overridden calc() operation
SHOW_EXPR(elms[1].getVal())
CHECK (elms[1].getVal() == (2+1)*1); // indeed a Num<2> with seed ≡ 1
SHOW_EXPR(elms[1].calc(1))
CHECK (elms[1].calc(1) == 2 + 1 + (1+1)); // indeed the overridden calc() picking from the Array(1,1)
SHOW_EXPR(elms[2].getVal())
CHECK (isLimited (1, elms[2].getVal(), 100'000'000)); // indeed a Dummy with default random seed
SHOW_EXPR(elms[3].getVal())
CHECK (isLimited (1, elms[3].getVal(), 100'000'000)); // and this one too, since we filled in two instances
SHOW_EXPR(elms[4].getVal())
CHECK (elms[4].getVal() == 5); // followed by tree instances Dummy(5)
SHOW_EXPR(elms[5].getVal())
CHECK (elms[5].getVal() == 5);
SHOW_EXPR(elms[6].getVal())
CHECK (elms[6].getVal() == 5);
SHOW_EXPR(elms[6].calc(1))
CHECK (elms[6].calc(1) == 5+1); // indeed invoking the base implementation of calc()
}
@ -148,11 +187,11 @@ namespace test{
}
/** @test TODO verify access operations on the actual container
/** @test TODO verify correct placement of instances within storage
* @todo WIP 6/24 🔁 define ⟶ implement
*/
void
check_ElementAccess()
check_ElementStorage()
{
}

281
wiki/thinkPad.ichthyo.mm
View file

@ -54468,6 +54468,58 @@
<node CREATED="1684890048701" ID="ID_1515151471" MODIFIED="1684890070142" TEXT="greift nested type bindings aus dem gegebenen value_type ab"/>
</node>
</node>
<node CREATED="1718111942637" ID="ID_120263382" MODIFIED="1718112119523" TEXT="Thema: Iteartor-Result-Move">
<linktarget COLOR="#4627b7" DESTINATION="ID_120263382" ENDARROW="Default" ENDINCLINATION="-1618;155;" ID="Arrow_ID_1994292406" SOURCE="ID_526580433" STARTARROW="None" STARTINCLINATION="-646;-77;"/>
<icon BUILTIN="yes"/>
<node CREATED="1718112123510" ID="ID_705868253" MODIFIED="1718112157586" TEXT="das Konzept ist stark festgelegt auf Ergebnisse per Referenz">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1718112188588" ID="ID_1868023012" MODIFIED="1718112197591" TEXT="das bedeutet: es gibt irgendwo einen verdeckten State"/>
<node CREATED="1718112199251" ID="ID_1861725707" MODIFIED="1718112222331" TEXT="dieser wird tempor&#xe4;r und gefiltert zug&#xe4;nglich gemacht"/>
<node CREATED="1718112294046" ID="ID_518216816" MODIFIED="1718112306889" TEXT="dem Konsumenten wird vertraut (er kann manipulieren)"/>
</node>
<node CREATED="1718112309252" ID="ID_953054375" MODIFIED="1718112363572" TEXT="ein generelles &#xbb;move-Iterator&#xab;-Konzept st&#xfc;nde dazu im Widerspruch">
<node CREATED="1718112367228" ID="ID_223213016" MODIFIED="1718112506954" TEXT="Lumiera-Iteratoren sind konzeptionell etwas anderes als STL-Iteratoren">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
STL-Iteratoren sind &#187;abstrahierte Pointer&#171; und setzen eigentlich die Idee eines Datencontainers vorraus. Das gilt nicht f&#252;r Lumiera-Iteratoren; diese sind nicht daf&#252;r gedacht, Container-<b>Inhalte</b>&#160; zu extrahieren oder zu manipulieren, sondern sie verk&#246;rpern eine <b>Folge von Berechnungen</b>.
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1718112560947" ID="ID_152744525" MODIFIED="1718112711362" TEXT="ein move-Result-Schalter k&#xf6;nnte in diesem Rahmen gef&#xe4;hrlichen Schaden anrichten">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...und zwar vor allem im Zusammenspiel mit dem zentralen Konzept einer &#187;State Core&#171; &#8212; der Nutzer sollte nicht dazu verleitet werden, zu viele Annahmen &#252;ber diesen State zu machen, ganz einfach, weil die Konsequenzen komplex und gedanklich schwer handhabbar sind. Das habe ich aus eigener Erfahrung gelernt (Stichwort der monadische Iter-Explorer)
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1718112713454" ID="ID_898118821" MODIFIED="1718112733048" TEXT="selbst die allgemeine effuse()-Funktion macht eine regul&#xe4;re Value-Kopie (und das ist gut so)"/>
</node>
<node CREATED="1718112738731" ID="ID_1653062696" MODIFIED="1718112774532" TEXT="Workaround: ein terminales foreach mit einem consumer-&#x3bb;">
<icon BUILTIN="idea"/>
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1718112799579" ID="ID_1514880244" MODIFIED="1718112833127" TEXT="f&#xfc;r dieses Thema wird grunds&#xe4;tzlich keine generische L&#xf6;sung bereitgestellt">
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="yes"/>
<node CREATED="1718112835366" ID="ID_1961949677" MODIFIED="1718112884871" TEXT="weder als Iterator-Adapter">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...w&#228;re eigentlich ganz billig zu haben, analog zu ConstIter
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1718112886431" ID="ID_996588888" MODIFIED="1718112899866" TEXT="noch als Terminal in IterEplorer"/>
<node CREATED="1718112914131" ID="ID_38982413" MODIFIED="1718112923134" TEXT="und auch nicht in speziellen Containern"/>
</node>
</node>
</node>
<node CREATED="1684279342553" ID="ID_289621340" MODIFIED="1684279366302" TEXT="diverse Auspr&#xe4;gungen">
<icon BUILTIN="info"/>
@ -81740,20 +81792,15 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1718064049623" ID="ID_442869624" MODIFIED="1718064442102">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
unser Storage-Puffer ist alignas(I) &#8212; das kann <b>zu locker</b>&#160;sein f&#252;r das tats&#228;chliche Objekt
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
<u>Beispiel</u>: <b><font face="Monospaced" color="#560799">I</font></b>&#160;ist eine leere Klasse, hat also sizeof(<b><font face="Monospaced" color="#560799">I</font></b>) &#8801; alignof(<b><font face="Monospaced" color="#560799">I</font></b>) &#8801; 1
@ -81768,8 +81815,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
&#10233; die naive L&#246;sung beginnt bei offset &#8788; 3 und f&#252;gt f&#252;r jeden Index +12 Bytes hinzu; damit sind <b>alle Objekte grob falsch ausgerichtet</b>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1718064447034" ID="ID_627454107" MODIFIED="1718064453581" TEXT="korrekt w&#xe4;re...">
<node CREATED="1718064454689" ID="ID_901534814" MODIFIED="1718064478465" TEXT="Anfang des Puffers am Anlignment der Elemente ausrichten"/>
@ -81780,16 +81826,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_ok"/>
<node CREATED="1718064618803" ID="ID_371062072" MODIFIED="1718064688256">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
man k&#246;nnte das nun&#160;<i>ungenau </i>oder <i>punktgenau</i>&#160;oder <i>grob korrekt </i>handhaben&#160;
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1718064742835" ID="ID_871080765" MODIFIED="1718064754941" TEXT="&#xbb;grob korrekt&#xab;">
<node CREATED="1718064756929" ID="ID_1870004223" MODIFIED="1718064798319" TEXT="w&#xe4;hle f&#xfc;r den Puffer das Alignment eines void* (&#xbb;slot&#xab;)"/>
@ -81927,16 +81970,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_ok"/>
<node CREATED="1717796640496" ID="ID_962872298" MODIFIED="1717796742452" TEXT="Begr&#xfc;ndung: Raum f&#xfc;r zuk&#xfc;nftige Optimierungen schaffen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Kann derzeit keine befriedigende L&#246;sung f&#252;r die diversen Zielkonflikte finden. Daher w&#228;hle ich eine L&#246;sung, die Raum f&#252;r zuk&#252;nftige L&#246;sungen schafft, und aktuell im Basisfall einfach und gradlinig zu implementieren ist. Speicher-Mehrverbrauch f&#252;r die Metadaten wird in Kauf genommen
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="info"/>
</node>
<node COLOR="#338800" CREATED="1717796744022" ID="ID_37258983" MODIFIED="1717804825999" TEXT="cnt-Parameter in das ArrayBucket">
@ -81964,16 +82004,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_ok"/>
<node CREATED="1718038819461" ID="ID_834949267" MODIFIED="1718038892881" TEXT="wird wohl eine State-Core-Impl">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
ein einfacher Pointer geht nicht, wegen dem anzuwendenden Spread
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1718039111176" ID="ID_679646830" MODIFIED="1718039131276" TEXT="sowas habe ich doch erst k&#xfc;rzlich implementiert....">
<icon BUILTIN="smiley-neutral"/>
@ -81995,16 +82032,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_ok"/>
<node CREATED="1718062164811" ID="ID_1792709896" MODIFIED="1718062223389">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
einfach ein <font face="Monospaced" color="#68360d">lib::IterIndex&lt;</font><font face="Monospaced" color="#9b1905">const</font><font face="Monospaced" color="#68360d">&#160;</font><font face="Monospaced" color="#7e1040">Several&lt;X&gt;</font><font face="Monospaced" color="#68360d">&gt;</font>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
</node>
@ -82478,16 +82512,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="yes"/>
<node CREATED="1717980667483" ID="ID_1900000633" MODIFIED="1717980709406">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
jetzt habe ich mich sowiso schon mal f&#252;r die <i><font color="#5c166e">vorl&#228;ufige Verschwendung</font></i>&#160;entschieden
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="ksmiletris"/>
</node>
<node CREATED="1717980713277" ID="ID_445857465" MODIFIED="1717980771913" TEXT="wenn das wirklich ein Problem ist, kann &#x201e;man&#x201c; sp&#xe4;ter immer noch was Kluges machen"/>
@ -82580,16 +82611,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1718073136703" ID="ID_1748624313" MODIFIED="1718073143770" TEXT="war erst eine Strategy-Klasse"/>
<node CREATED="1718073144358" ID="ID_1791928342" MODIFIED="1718073320994" TEXT="jetzt direkt in die SeveralBuilder-Implementierung integriert">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...das mach die Verwendung einfacher (kein &quot;template&quot;-Pr&#228;fix vor jeder Methode) und speziell das Deleter-&#955; kann nun direkt auf die geerbte Factory mit dem eingebetteten Allokator durchgreifen; ja der Code ist inzwischen riesengro&#223;, aber alles h&#228;ngt irgendwie mit allem zusammen, und ich sehe nicht, wie ich hier eine Teilkomponente so extrahieren k&#246;nnte, da&#223; der Code wirklich einfacher wird. Jedenfalls die separate Strategy-Klasse ist es nicht...
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
</node>
@ -82686,16 +82714,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1717894097677" ID="ID_296210161" MODIFIED="1717894105895" TEXT="entweder memmove"/>
<node CREATED="1717894106512" ID="ID_1351589328" MODIFIED="1717894141182">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
oder es wird <b>ausschlie&#223;lich</b>&#160;der Element-Typ E konstruiert
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
<node COLOR="#435e98" CREATED="1717980924344" ID="ID_599080738" MODIFIED="1717980947745" TEXT="L&#xf6;sung: auch die AllocationPolicy zus&#xe4;tzlich auf E templaten">
@ -82707,16 +82732,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="help"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1717894328830" ID="ID_1955150114" MODIFIED="1717894371012">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
Vorsicht: hab es aus der <font face="Monospaced" color="#6a2f3c"><b>emplaceElm()</b></font>-Funktion entfernt
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1717980838451" ID="ID_123345043" MODIFIED="1717980849735" TEXT="hab es jetzt vorerst doch wieder dorthin geschoben"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1717980850354" ID="ID_1951694568" MODIFIED="1717980857530" TEXT="TODO: bessere L&#xf6;sung finden">
@ -82728,16 +82750,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1717894472499" ID="ID_534883946" MODIFIED="1717894525092" TEXT="Aber: wird erst relevant wenn tats&#xe4;chlich Objekte verschoben werden m&#xfc;ssen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...und das kann vom Allokator abh&#228;ngen
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="flag-pink"/>
</node>
</node>
@ -82791,16 +82810,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1717943774986" ID="ID_1922725758" MODIFIED="1717943879338" TEXT="auch f&#xfc;r &#xbb;unmanaged&#xab;-Allokatoren den Destruktor aufrufen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...man k&#246;nnte geneigt sein, das zu &#252;berspringen; aber ich entscheide mich hier <b>explizit dagegen</b>, weil es <i>gegen den Stil von C++ verst&#246;&#223;t.</i>&#160;Wenn man den Deleter-Aufruf vermeiden will, dann soll man eben triviale Objekte verwenden. Ende der Diskussion.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="yes"/>
</node>
@ -82815,16 +82831,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1718073482321" ID="ID_1354135269" MODIFIED="1718073503220" TEXT="es gen&#xfc;gt, diese delete()-Funktion in ein Lambda zu packen"/>
<node CREATED="1718073503837" ID="ID_187787677" MODIFIED="1718073530823">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
Trick: capture der factory per value &#10233; <b>Kopie des Allokators</b>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="forward"/>
</node>
</node>
@ -82861,31 +82874,25 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="clanbomber"/>
<node CREATED="1717771137791" ID="ID_1321354068" MODIFIED="1717771166027">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
das ist jetzt <b>noch ein weiteres</b>&#160;extra Datenfeld
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="smily_bad"/>
<node CREATED="1717771172737" ID="ID_339804394" MODIFIED="1717771190676" TEXT="das l&#xe4;ge zwar im Bucket in der Storage"/>
<node CREATED="1717771200623" ID="ID_79846525" MODIFIED="1717771208658" TEXT="trotzdem &#xe4;rgerlich">
<node CREATED="1717771319363" ID="ID_165772412" MODIFIED="1717771389855" TEXT="weil es f&#xfc;r den Haupt-Anwendungsfall gar nicht gebraucht wird">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
denn der Allocation-Cluster wei&#223; selber die Zahl seiner belegten Roh-Bl&#246;cke; zur de-Allokation mu&#223; ansonsten gar nichts gemacht werden
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1717771640460" ID="ID_1646507168" MODIFIED="1717771661118" TEXT="weil die Datenstruktur doch so sch&#xf6;n elegant sein sollte....">
<icon BUILTIN="smiley-oh"/>
@ -82899,16 +82906,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1717771768371" ID="ID_370564159" MODIFIED="1717771775678" TEXT="sicher und klar"/>
<node CREATED="1717771790928" ID="ID_1239859891" MODIFIED="1717772007103" TEXT="Irre verschwenderisch">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Der vermutlich h&#228;ufigste Fall ist ein Several&lt;ProcNode*&gt; &#8212; mit typischerweise genau einem Element mit einem &#187;Slot&#171;Gr&#246;&#223;e. Daf&#252;r haben wir jetzt schon 4 &#187;Slot&#171; Overhead, und jetzt sollen das 5 &#187;Slot&#171; werden....
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
<node CREATED="1717771727481" ID="ID_1872517693" MODIFIED="1717771751937" TEXT="am Ende des Build-Vorganges stets ein shrink-to-fit machen">
@ -82922,43 +82926,34 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1717773280353" ID="ID_1332303474" MODIFIED="1717773295509" TEXT="alle weiteren Metadaten liegen im ArrayBucket"/>
<node CREATED="1717773296351" ID="ID_129834213" MODIFIED="1717773606110" TEXT="dabei wird ein spezielles optimiertes Placement verwendet">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...das hei&#223;t, wir verwenden im ersten &#187;Slot&#171; ein Bit-Feld, da die Zahl der Elemente ohnehin praktisch begrenzt ist (auf ein paar Hundert); in den freien oberen Bits kann daher das konkrete weitere Layout encodiert werden. Das kostet nur einen minimalen Runtime-Overhead (ein paar Bit-Manipulationen vor der Indirektion zum Datenelement, welches ebenfalls im Cache liegt). Der intendierte use-case nutzt diese Collection als Basis einer verzeigerten Datenstruktur, und nicht in einer innersten Loop.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
<node CREATED="1717773313924" ID="ID_1133884189" MODIFIED="1717773348408" TEXT="im wichtigsten Standardfall kann damit die Storage auf 1 &#xbb;slot&#xab; reduziert werden">
<icon BUILTIN="idea"/>
</node>
<node CREATED="1717773611076" ID="ID_569133844" MODIFIED="1717773685833">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
<u>besonderes geschickt</u>: <i>man kann das &#8222;sp&#228;ter mal&#8220; machen</i>
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Denn Lumiera hat im Moment wirklich andere Sorgen, als die Optimierung einer nocht-gar-nicht-wirklich-genutzten Datenstruktur
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
</node>
@ -82977,16 +82972,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1717858386974" ID="ID_319057950" MODIFIED="1717858400465" TEXT="bekommt nur noch die geforderte Zielkapazit&#xe4;t"/>
<node CREATED="1717858221198" ID="ID_13569379" MODIFIED="1717858362700" TEXT="keine Pr&#xfc;fung der Handhabbarkeit mehr">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
die grunds&#228;tzliche M&#246;glichkeit der Anpassung ist bereits vorher sichergestellt, denn der veranlassende API-call w&#228;re sonst schon per Exception abgebrochen worden
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="yes"/>
</node>
</node>
@ -83003,16 +82995,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1717871630138" ID="ID_162586833" MODIFIED="1717871634709" TEXT="Aktions-Logik">
<node CREATED="1717872018862" ID="ID_1125014762" MODIFIED="1717872426247" TEXT="Spread wird nur vergr&#xf6;&#xdf;ert">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Das ist eine Festlegung aus pragmatischen Gr&#252;nden; weder der Container noch der Builder erfasst den Typ einzelner Elemente, daher gibt es auch keine M&#246;glichkeit, &#252;bersch&#252;ssigen Spread festzustellen. Zwar k&#246;nnte der Client-Code diese Information besitzen, aber dann k&#246;nnte er auch gleich richtig dimensionieren. Generell wird der &#196;nderung des Spread keine besondere Bedeutung zugemessen &#8212; wenn es geht, wird's gemacht.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="yes"/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1717884512847" ID="ID_1565824800" MODIFIED="1717884527086" TEXT="Design-Schwierigkeiten">
@ -83025,16 +83014,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1717873749393" ID="ID_1296625980" MODIFIED="1717884523389" TEXT="inkrementelle Wahl der Puffergr&#xf6;&#xdf;e ist komplex und zustandsabh&#xe4;ngig">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
der Puffer sollte mit einem Initial-Wert beginnen, und dann in Verdoppelungs-Schriten wachsen; Verdoppelung setzt nat&#252;rlich Kenntnis der aktuellen Puffergr&#246;&#223;e voraus; dabei g&#228;be es aber auch noch einen Maximalwert zu beachten, der vom Allokator abh&#228;ngen kann.
</p>
</body>
</html>
</richcontent>
</html></richcontent>
</node>
</node>
<node CREATED="1717884537799" ID="ID_869921208" MODIFIED="1717884548769" TEXT="die Logik umdrehen">
@ -83079,6 +83065,27 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1716914892972" ID="ID_1080699305" MODIFIED="1716914902543" TEXT="Platzieren neuer Daten">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1718109947743" ID="ID_1627078678" MODIFIED="1718113032356" TEXT="Anforderungen">
<icon BUILTIN="yes"/>
<node CREATED="1718109979283" ID="ID_249817182" MODIFIED="1718109999348" TEXT="kann Inhalte aus einem Iterator kopieren"/>
<node CREATED="1718110015366" ID="ID_1082498167" MODIFIED="1718110031031" TEXT="kann einzelne Elemente mit frei w&#xe4;hlbarem Typ und Argumenten konstruieren"/>
<node CREATED="1718110151884" ID="ID_266751076" MODIFIED="1718110198257" TEXT="kann heterogene Folge von Elementen (per copy/move) &#xfc;bernehmen"/>
<node CREATED="1718115611034" ID="ID_1154907054" MODIFIED="1718115723496" TEXT="kann N Elemente vom Standard-Typ einf&#xfc;llen"/>
<node COLOR="#435e98" CREATED="1718111916441" ID="ID_526580433" MODIFIED="1718112933083" TEXT="sind moves/-RRefs relevant?">
<arrowlink COLOR="#4627b7" DESTINATION="ID_120263382" ENDARROW="Default" ENDINCLINATION="-1618;155;" ID="Arrow_ID_1994292406" STARTARROW="None" STARTINCLINATION="-646;-77;"/>
<node CREATED="1718112935024" ID="ID_887174980" MODIFIED="1718112949722" TEXT="Antwort: diese T&#xfc;r wollen wir nicht aufmachen"/>
<node CREATED="1718112972676" ID="ID_1976405326" MODIFIED="1718112991856" TEXT="der Client soll sich jedesmal selber darum bem&#xfc;hen m&#xfc;ssen"/>
<node CREATED="1718112999843" ID="ID_743106947" MODIFIED="1718113018646" TEXT="es gibt einen einfachen Workaround: ein terminales foreach-&#x3bb;">
<icon BUILTIN="idea"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1718113039814" ID="ID_553490359" MODIFIED="1718118077881" TEXT="Implementierung durch Delegation">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1718118079617" ID="ID_786279389" LINK="#ID_748929457" MODIFIED="1718118116331" TEXT="Testen mit allen Schikanen">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1716936138265" ID="ID_344813639" MODIFIED="1716936143886" TEXT="Allokations-Policies">
<icon BUILTIN="flag-yellow"/>
@ -83096,16 +83103,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1717794550220" ID="ID_1034302214" MODIFIED="1717794631737" TEXT="das ist hier eine besondere Herausforderung....">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...aufgrund der Flexibilit&#228;t ist das intendierte Verhalten nicht mehr einfach zu fassen; es ist eigens ein Zugangsweg zu finden, um die richtige Logik zu entwickeln---
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1717794645742" ID="ID_1610453521" MODIFIED="1717796458652" TEXT="Methode: den Lebenszyklus konzeptionell durchgehen">
@ -83176,9 +83180,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1717807297399" ID="ID_1804457131" MODIFIED="1717807324080" TEXT="und trivially_move_constructible"/>
<node CREATED="1717808984189" ID="ID_1035267118" MODIFIED="1717809129192" TEXT="und: I &#x2227; E sind ebenfalls trivially_move_constructible">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Vorsicht Falle!
@ -83187,8 +83189,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
Ohne diesen Check w&#252;rden wir uns in den Fu&#223; schie&#223;en, wenn wir den Container in den wild-move-Modus schalten, denn Elemente vom Typ E oder I k&#246;nnten stets ohne Weiteres noch dazukommen
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
</node>
<node CREATED="1717809142579" ID="ID_528651025" MODIFIED="1717809223883" TEXT="Vorsicht: auch Ausschlu&#xdf; pr&#xfc;fen falls wild-move-Flag gesetzt"/>
@ -83257,16 +83258,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#338800" CREATED="1718034918473" ID="ID_476774347" MODIFIED="1718035008717" TEXT="banal: mu&#xdf; den move-ctor explizit implementieren">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn die default-Impl kopiert skalare Typen lediglich; hier m&#252;ssen wir sie aber wirklich austauschen, damit nur eine Instanz den aktiven Pointer h&#228;lt...
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="button_ok"/>
</node>
</node>
@ -83276,16 +83274,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1718035045791" ID="ID_1798109493" MODIFIED="1718035049107" TEXT="Debugger....">
<node COLOR="#435e98" CREATED="1718035376451" ID="ID_63179085" MODIFIED="1718037484514" TEXT="Bug-1: storageBytes f&#xe4;lschlich als buffSiz verwendet">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
storageBytes wird nur in der Factory ben&#246;tigt und ist die Gr&#246;&#223;e der gesamten Allokation incl Admin-Overhead
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="broken-line"/>
</node>
<node COLOR="#338800" CREATED="1718037328595" ID="ID_1441998477" MODIFIED="1718037494401" TEXT="Bug-1b: der gleiche Denkfehler steckt auch im Destruktor">
@ -83294,16 +83289,13 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node COLOR="#435e98" CREATED="1718036083452" ID="ID_1947157945" MODIFIED="1718037527996" TEXT="problematisch: Element-dtor bekommt Vorrang vor trivialem dtor">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
....und das wird praktisch immer greifen, wenn Element-Typ und Interface-Typ identisch sind; es steht zu bef&#252;rchten da&#223; deshalb der <i>triviale destruktur praktisch nie zum Tragen kommt. </i>Anders herum best&#252;nde auch keine Gefahr, da&#223; ein erstes Element, das auch ein Subtyp sein k&#246;nnte, eine Entscheidung f&#252;r TRIVIAL f&#228;llen w&#252;rde, denn der ELEMENT-Fall fordert ja grade, da&#223; alle Elemente den gleichen Typ haben; also w&#228;re eine solche Festlegung auch in diesem Fall sogar vorteilhaft, da sie den Destruktor-Aufruf einspart
</p>
</body>
</html>
</richcontent>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
</node>
<node COLOR="#435e98" CREATED="1718037202167" ID="ID_1048518309" MODIFIED="1718037603875" TEXT="Bug-2: Code f&#xfc;r front() und back() vertauscht (und verwendet falsches Meta-Feld)">
@ -83316,11 +83308,26 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_ok"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1716857382441" ID="ID_748929457" MODIFIED="1716857402102" TEXT="check_Builder">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1716857382441" ID="ID_748929457" MODIFIED="1718118121268" TEXT="check_Builder">
<icon BUILTIN="pencil"/>
<node CREATED="1718118125770" ID="ID_1218727200" MODIFIED="1718118149459" TEXT="Container Basistyp + beliebige Subklassen"/>
<node CREATED="1718122126403" ID="ID_749733199" MODIFIED="1718122206871" TEXT="Basistyp und beliebiger Typ &#x27f9; wilder cast"/>
<node CREATED="1718122626451" ID="ID_142448404" MODIFIED="1718122636499" TEXT="Iterator einf&#xfc;llen"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1716857382441" ID="ID_610081580" MODIFIED="1716857402102" TEXT="check_ErrorHandling">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1718121991093" ID="ID_70431031" MODIFIED="1718121997497" TEXT="Base + beliebiger Typ">
<node CREATED="1718121998540" ID="ID_160009328" MODIFIED="1718122009540" TEXT="Typ zu gro&#xdf;"/>
<node CREATED="1718122010547" ID="ID_1757791910" MODIFIED="1718122019981" TEXT="nicht gen&#xfc;gend Storage und kann nicht verschieben"/>
</node>
<node CREATED="1718122030712" ID="ID_1960968889" MODIFIED="1718122040234" TEXT="Base + bekanntes E">
<node CREATED="1718122066531" ID="ID_1633309056" MODIFIED="1718122076582" TEXT="kann wachsen (da move-ctor bekannt)"/>
<node CREATED="1718122077386" ID="ID_959961694" MODIFIED="1718122087388" TEXT="kann keinen anderen Typ platzieren (selbst wenn kleiner)"/>
</node>
<node CREATED="1718122252659" ID="ID_616405505" MODIFIED="1718122291873" TEXT="Triviale Typen">
<node CREATED="1718122293022" ID="ID_697520417" MODIFIED="1718122302248" TEXT="kann wachsen"/>
<node CREATED="1718122302932" ID="ID_293207594" MODIFIED="1718122311738" TEXT="kann spread &#xe4;ndern"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1716857382441" ID="ID_1397767362" MODIFIED="1716857402102" TEXT="check_ElementAccess">
<icon BUILTIN="flag-yellow"/>