Library: draft a simpler STL complient allocation interface
After some analysis, it became clear that the existing code for `AllocationCluster` (while in itself valid) will likely miss the point for the expected usage in the low-level Model: most segments of the model will be rather small, and thus there is not enough potential for amortisation when using such a per-type and per-segment scheme; a rather simplistic linear allocator will be sufficient. On the other hand, with the current C++ standard it is easy to provide a complient allocator implementation for STL containers, and thus the interface should be retro-fitted accordingly.
This commit is contained in:
parent
db30da90ce
commit
fd49c68096
2 changed files with 526 additions and 16 deletions
|
|
@ -29,14 +29,9 @@
|
|||
** as a whole. AllocationCluster implements memory management to
|
||||
** support this usage pattern.
|
||||
**
|
||||
** @note this file is organised in a way which doesn't bind the
|
||||
** client code to the memory manager implementation. Parts of the
|
||||
** interface depending on the usage situation are implemented using
|
||||
** templates, and thus need to be in the header. This way they can
|
||||
** exploit the type information available in call context. This
|
||||
** information is passed to generic implementation functions
|
||||
** defined in allocation-cluster.cpp . In a similar vein, the
|
||||
** AllocationCluster::MemoryManger is just forward declared.
|
||||
** @warning in rework 5/2024 — with the goal to simplify the logic,
|
||||
** remove all thread safety and make the implementation
|
||||
** usable as standard conformant allocator for STL.
|
||||
**
|
||||
** @see allocation-cluster-test.cpp
|
||||
** @see builder::ToolFactory
|
||||
|
|
@ -89,9 +84,22 @@ namespace lib {
|
|||
* Is this issue worth the hassle? //////////////////////////////TICKET #169
|
||||
*/
|
||||
class AllocationCluster
|
||||
: util::NonCopyable
|
||||
: util::MoveOnly
|
||||
{
|
||||
|
||||
template<typename X>
|
||||
struct Allocator
|
||||
{
|
||||
using value_type = X;
|
||||
|
||||
[[nodiscard]] X* allocate (size_t n) { return mother_->allot<X>(n); }
|
||||
void deallocate (X*, size_t) noexcept { /* rejoice */ }
|
||||
|
||||
Allocator(AllocationCluster* m) : mother_{m} { }
|
||||
private:
|
||||
AllocationCluster* mother_;
|
||||
};
|
||||
|
||||
public:
|
||||
AllocationCluster ();
|
||||
~AllocationCluster () noexcept;
|
||||
|
|
@ -101,8 +109,14 @@ namespace lib {
|
|||
TY&
|
||||
create (ARGS&& ...args)
|
||||
{
|
||||
TY* obj = new(allocation<TY>()) TY (std::forward<ARGS> (args)...);
|
||||
return commit(obj);
|
||||
return * new(allotMemory (sizeof(TY))) TY (std::forward<ARGS> (args)...);
|
||||
}
|
||||
|
||||
template<typename X>
|
||||
Allocator<X>
|
||||
getAllocator()
|
||||
{
|
||||
return Allocator<X>{this};
|
||||
}
|
||||
|
||||
|
||||
|
|
@ -115,6 +129,24 @@ namespace lib {
|
|||
|
||||
|
||||
private:
|
||||
/**
|
||||
* portion out the requested amount of memory,
|
||||
* possibly claiming a new pool block.
|
||||
*/
|
||||
void*
|
||||
allotMemory (size_t bytes)
|
||||
{
|
||||
UNIMPLEMENTED ("actual memory management");
|
||||
}
|
||||
|
||||
template<typename X>
|
||||
X*
|
||||
allot (size_t cnt =1)
|
||||
{
|
||||
return static_cast<X*> (allotMemory (cnt * sizeof(X)));
|
||||
}
|
||||
|
||||
|
||||
/** initiate an allocation for the given type */
|
||||
template<class TY>
|
||||
void*
|
||||
|
|
|
|||
|
|
@ -80681,6 +80681,37 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1715625161792" ID="ID_748407633" MODIFIED="1715625275278" TEXT="Zweifel an bestehender Allocation-Cluster-Implemenierung">
|
||||
<arrowlink COLOR="#fd2206" DESTINATION="ID_741455291" ENDARROW="Default" ENDINCLINATION="371;-21;" ID="Arrow_ID_148841438" STARTARROW="None" STARTINCLINATION="988;41;"/>
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1715625311161" ID="ID_1762606958" MODIFIED="1715625461924" TEXT="der unterliegende Memory-Manager ist ungeklärt">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
An der Stelle habe ich nicht weiter analysiert, sondern einfach Heap-Allokationen gemacht; der Grund seinerzeit war, daß Christian den »Mempool« überall einführen wollte — ein Ansatz, den ich grundsätzlich unterstützte, wenngleich auch seine Implementierung zu einfach war, und ich damit diesen use-Case nicht sauber realisieren konnte. Damit unterblieben aber weitere Überlegungen zum Allocation-Trend
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1715625485709" ID="ID_323773842" MODIFIED="1715625503477" TEXT="zu viel Locking — und möglicherweise an der falschen Stelle"/>
|
||||
<node CREATED="1715625511889" HGAP="39" ID="ID_1920622182" MODIFIED="1715625840520" TEXT="Effizienz der Familien-Pools erscheint fragwürdig" VSHIFT="-29">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
damals hatte ich als Vorbild den <i>small-objects pool allocator </i>von Alexandrescu im Kopf; deshalb habe ich auch »Familien« von Objekten vorgesehen — ohne jedoch zu klären, ob und wie sich daraus ein Amortisierungs-Effekt ergibt. Nach gründlicherer Überlegung erscheint mir das als ein Widerspruch im Konzept, denn diese small-objects-Pools laufen ja auf ein Tiling mit fortlaufend stattfindedenden Allokationen hinaus; das ist exakt das Gegenteil von dem, was mir hier vorschwebt. Damit würden die Einzelpools nur Administrations-Overhead verursachen, der seine Vorteile überhaupt nicht ausspielen kann; stattdessen sollte besser in Betracht gezogen werden, alles heterogen, so wie es kommt, in größere Blöcke zu packen. Das Tiling würde damit auf einem größeren Level stattfinden, und wäre in den Basis-Allocator verlagert...
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1714870490954" ID="ID_433835630" MODIFIED="1714870505595" TEXT="Aufräumen">
|
||||
<node CREATED="1714870511447" ID="ID_698798351" MODIFIED="1714870529856" TEXT="NodeGraphAttachment in ExitNode umwandeln"/>
|
||||
<node CREATED="1714870530945" ID="ID_1030439043" MODIFIED="1714870546389" TEXT="bisherige skizzierte Rolle er ExitNode zurückbauen"/>
|
||||
|
|
@ -80987,6 +81018,29 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node CREATED="1715532615345" ID="ID_1951577105" MODIFIED="1715532623856" TEXT="keinerlei Container-Mutation"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715618121025" ID="ID_1771703333" MODIFIED="1715618125167" TEXT="usage-patterns">
|
||||
<node CREATED="1715618155444" ID="ID_787577497" MODIFIED="1715618165722" TEXT="stets: bauen und dann unverändert verwenden"/>
|
||||
<node CREATED="1715618167076" ID="ID_407732173" MODIFIED="1715618185087" TEXT="Fall-1 : bekannte Zahl an Elementen wird schrittweise zusammengebaut"/>
|
||||
<node CREATED="1715618185979" ID="ID_342860962" MODIFIED="1715618213307" TEXT="Fall-2 : Exploration liefert unbekannte Zahl an Elementen zur Konfiguration"/>
|
||||
<node CREATED="1715618232322" ID="ID_682478842" MODIFIED="1715618242095" TEXT="Vergleich mit bestehenden Containern">
|
||||
<node CREATED="1715618254530" ID="ID_1519146754" MODIFIED="1715618257565" TEXT="Vector">
|
||||
<node CREATED="1715618258391" ID="ID_38531723" MODIFIED="1715618264773" TEXT="unterstützt alle diese Pattern"/>
|
||||
<node CREATED="1715618266011" ID="ID_203372325" MODIFIED="1715618270124" TEXT="ist dann aber mutable"/>
|
||||
<node CREATED="1715618270856" ID="ID_1061712193" MODIFIED="1715618293534" TEXT="keine non-copyable elements"/>
|
||||
</node>
|
||||
<node CREATED="1715618298684" ID="ID_631212658" MODIFIED="1715618302184" TEXT="ScopedCollection">
|
||||
<node CREATED="1715618303668" ID="ID_935483598" MODIFIED="1715618310854" TEXT="unterstützt nur Fall-1"/>
|
||||
<node CREATED="1715618311442" ID="ID_1623386726" MODIFIED="1715618330992" TEXT="unterstützt ein weiteres Muster (RAII / Populator)"/>
|
||||
<node CREATED="1715618379385" ID="ID_825375134" MODIFIED="1715618385077" TEXT="erlaubt non-copyable elements"/>
|
||||
<node CREATED="1715618703910" ID="ID_753044820" MODIFIED="1715618720116" TEXT="(bisher) nur Heap-Allokation"/>
|
||||
</node>
|
||||
<node CREATED="1715618477780" ID="ID_1982987663" MODIFIED="1715618480152" TEXT="Deque">
|
||||
<node CREATED="1715618481364" ID="ID_340038086" MODIFIED="1715618491385" TEXT="unterstützt beide Pattern"/>
|
||||
<node CREATED="1715618491930" ID="ID_332936386" MODIFIED="1715618499605" TEXT="erlaubt non-copyable elements"/>
|
||||
<node CREATED="1715618597349" ID="ID_1869583826" MODIFIED="1715618611414" TEXT="aber keine continuous storage"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715532630466" ID="ID_169592902" MODIFIED="1715533548154" TEXT="muß dazu passenden Builder konzipieren...">
|
||||
<font NAME="SansSerif" SIZE="12"/>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1715532833936" ID="ID_1009009693" MODIFIED="1715532840949" TEXT="Problem: Link zum Allocator">
|
||||
|
|
@ -81067,7 +81121,292 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<edge COLOR="#fe0606"/>
|
||||
<font NAME="SansSerif" SIZE="14"/>
|
||||
<icon BUILTIN="clanbomber"/>
|
||||
<node CREATED="1715618831175" HGAP="41" ID="ID_891863283" MODIFIED="1715618893746" STYLE="fork" TEXT="Auswege..." VSHIFT="41">
|
||||
<edge COLOR="#6a3645" STYLE="linear"/>
|
||||
<node CREATED="1715618937215" ID="ID_975786159" MODIFIED="1715619229829" TEXT="Tag oder Allocator-Link in jeder Instanz">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
Sorge:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
ich erwarte ~10k Nodes im Modell
|
||||
</li>
|
||||
<li>
|
||||
die meisten Nodes haben nur einen Vorläufer / Nachfolger
|
||||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
⟹ bläht die Storage um 30% auf
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1715618955861" ID="ID_189897298" MODIFIED="1715619378057" TEXT="dann halt doch bloß Heap-Allokationen machen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
Da der Heap-Allokator inzwischen ziemlich performant ist, könnte man damit durchkommen...
|
||||
</p>
|
||||
<p>
|
||||
Sorgen:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
wenn es dann doch Probleme gibt, ist der Zug bereits abgefahren (weil Allokationen überall im Code passieren)
|
||||
</li>
|
||||
<li>
|
||||
auf anderen Plattformen kann die Performance vom Heap-Allocator ganz anders sein, und wir haben darauf keinerlei Einfluß
|
||||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1715620143727" ID="ID_828708828" MODIFIED="1715620159863" TEXT="Zugriff auf den Allocator per DI (statisch) oder Thread-local"/>
|
||||
<node CREATED="1715620242056" ID="ID_427769562" MODIFIED="1715620649844" TEXT="Spezieller Allocator mit Block-de-Allocation">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...man verwendet <i>nur speziell im produktiven Einsatz im Node-Graph</i>  einen besonderen Allocator, der zwar den Destruktor aufruf, aber den Speicher nicht freigibt; alloziert wird immer in einen kompakten Block hinein, der dann auf der Basis der Prozeß-Kenntnis als Ganzes verworfen und neu verwendet wird.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="forward"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715624536080" ID="ID_614918224" MODIFIED="1715624543338" TEXT="Entscheidungen">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1715624583813" ID="ID_1547806624" MODIFIED="1715624601374" TEXT="einfache begin/end-Pointer - Implementierung">
|
||||
<node CREATED="1715624604522" ID="ID_1995705427" MODIFIED="1715624613764" TEXT="analog zu std::vector"/>
|
||||
<node CREATED="1715624614444" ID="ID_1920430377" MODIFIED="1715624773441" TEXT="direkt implementieren erscheint sinnvoll">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...weil std::vector zwar bereits alles bietet, aber eingebettet in sehr komplexen Code — im Besonderen dürfte es schwierig werden, das Thema on-demand-growth vs non-copyable zu umschiffen
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715624963026" ID="ID_744219090" MODIFIED="1715624972411" TEXT="separaten Builder für die zwei Nutz-Muster">
|
||||
<node CREATED="1715624984553" ID="ID_1271849826" MODIFIED="1715625002785" TEXT="open-sized + move-only"/>
|
||||
<node CREATED="1715625004020" ID="ID_863474418" MODIFIED="1715625011022" TEXT="fixed-size + noncopyable"/>
|
||||
</node>
|
||||
<node CREATED="1715625022874" ID="ID_158782942" MODIFIED="1715625045459" TEXT="Allocator externalisieren (wie in STDL-Containern)"/>
|
||||
<node CREATED="1715627229164" ID="ID_1793700784" MODIFIED="1715627351601" TEXT="das Concept ist für später aufgehoben">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...das heißt, ich gehe mal davon aus, daß ich mit einer einzigen, dedizierten Implementierung erst mal den aktuellen Bedarf decken kann; daraus könnte allerdings später immer noch ein Concept gemacht werden, welches dann alternativ auch durch ScopedCollection oder durch eine embedded-storage-Lösung erfüllt werden kann.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715625068841" ID="ID_273362995" MODIFIED="1715625074791" TEXT="Implementierung">
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1715625094577" ID="ID_1764137888" MODIFIED="1715625115360" TEXT="muß Allocator-Integration klären">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1715625132676" ID="ID_741455291" MODIFIED="1715625275278" TEXT="bestehende Allocation-Cluster-Impl erscheint nicht ganz passend">
|
||||
<linktarget COLOR="#fd2206" DESTINATION="ID_741455291" ENDARROW="Default" ENDINCLINATION="371;-21;" ID="Arrow_ID_148841438" SOURCE="ID_748407633" STARTARROW="None" STARTINCLINATION="988;41;"/>
|
||||
<node CREATED="1715625871491" ID="ID_1677812273" MODIFIED="1715626046458" TEXT="man kann das definitiv passender implementieren">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
heterogene Allokation in eine Sequenz größerer Blöcke; keinerlei de-Allokation und kein Locking
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1715625881800" ID="ID_1460908503" MODIFIED="1715626254822" TEXT="man könnte aber die bestehende Impl. erst mal ungesehen verwenden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...sie ist ja fertig und getestet, und wartet seit Jahren auf ihren Einsatz; allerdings wäre ein solches Vorgehen erklärungsbedürftig
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
man tut so, als wäre etwas in Ordnung, das nicht in Ordnung ist
|
||||
</li>
|
||||
<li>
|
||||
die bestehende Implementierung ist sogar maximal-dämlich
|
||||
</li>
|
||||
<li>
|
||||
und bietet zudem keinen guten Pfad zur Weiterentwicklung, sondern müßte irgendwann ersetzt werden
|
||||
</li>
|
||||
<li>
|
||||
allerdings spielt das Thema vermutlich lange Zeit gar keine Rolle (solange wir nicht sehr große Modelle bauen)
|
||||
</li>
|
||||
</ul>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1715625901869" ID="ID_460237769" MODIFIED="1715626344549" TEXT="oder aber gleich ganz liegen lassen und bloß Heap-Allokationen machen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...<i>wenn man schon </i>die bestehenden Implementierung nutzt (wohl wissend, daß ihre inhärenten Probleme erst mal nicht relevant sind), dann kann man genausogut <i>ganz auf blöd </i>sich auf den KISS-Standpunkt stellen und einfach Heap-Allokationen machen, denn die sind heutzutage verdammt effizient geworden
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1715625929114" ID="ID_704028431" MODIFIED="1715625953412">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...und alles das läuft auf weitere <b>technische Schulden</b> hinaus
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715626381670" ID="ID_365556330" MODIFIED="1715626396019" TEXT="Idee: den Allocation-Cluster unter gleichem Namen im Grund neu schreiben">
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1715626414697" ID="ID_280677111" MODIFIED="1715626425820" TEXT="durch den Namen wäre die Kontinuität pro Forma gewahrt"/>
|
||||
<node CREATED="1715626476945" ID="ID_1929954995" MODIFIED="1715626592916" TEXT="es gibt bisher nur minimale / vorbereitende Verwendungen">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...die allesamt mit dem Model + Player zu tun haben; einzige externe Verkoppelung ist der LinkedElements_test, und auch dieser stellt explizit einen Vorgriff auf die Verwendung im low-level-Model dar.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1715626599088" ID="ID_1068758723" MODIFIED="1715626653670" TEXT="das API ist schmal und könnte inkrementell umgestaltet werden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...da der davon abhängende Code <i>effektiv nur compilierbar ist, aber nicht lauffähig</i>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1715626710965" ID="ID_1722763351" MODIFIED="1715626721940" TEXT="die neue Lösung wäre in jedem Fall einfacher">
|
||||
<node CREATED="1715626738174" ID="ID_714358898" MODIFIED="1715626997202" TEXT="alles Locking fällt weg"/>
|
||||
<node CREATED="1715626731957" ID="ID_454366756" MODIFIED="1715626737099" TEXT="die Typ-Slots fallen weg"/>
|
||||
<node CREATED="1715626755683" ID="ID_714015643" MODIFIED="1715626839992" TEXT="das "commit"-Konzept wird aufgegeben">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
let it crash — wenn tatsächlich eine Exception fliegt, ist es ziemlich wahrscheinlich, daß der ganze Cluster sowiso weggeworfen wird; wenn nicht, dann akzeptieren wir einfach toten Speicher.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1715626853846" ID="ID_540898270" MODIFIED="1715626985387">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
die Bedeutung ist <b>geringer geworden</b>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
seinerzeit habe ich im AllocationCluster etwas gesehen, daß pervasiv überall im Code verwendet wird, analog zum Mempool. Inzwischen stehe ich auf dem Standpunkt, daß für die meisten Allokationen der Standard-Heap-Allokator sowiso gut genug ist (oder man nutzt ohnehin den Stack oder eine statische Variable); spezielle Allokatoren sind nach meinem heutigen Verständnis nur noch sinnvoll, wenn sie extrem spezifisch sind
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715627027263" ID="ID_1272289707" MODIFIED="1715627051080" TEXT="Aufgabe: den Standard-Allocator besser verstehen">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1715627069918" ID="ID_1496924967" MODIFIED="1715627170299" TEXT="es könnte nämlich eine Konvergenz geben">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...oder zumindest könnte man ein limitiertes Teil-Konzept umsetzen; mir fällt auf, daß diverse Methoden im Standard-Allocator inzwischen durch Traits ersetzt wurden.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<node CREATED="1715725369201" ID="ID_1600204256" MODIFIED="1715725381650" TEXT="tatsächlich ist es heutzutage sehr einfach"/>
|
||||
<node CREATED="1715725400796" ID="ID_1894647974" MODIFIED="1715725416576" TEXT="praktisch jeder custom-allocator kann standardkonform gemacht werden">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715693133661" ID="ID_868305899" MODIFIED="1715725332461" TEXT="Info zum Allocator-Gebrauch">
|
||||
<arrowlink COLOR="#4961d5" DESTINATION="ID_152113212" ENDARROW="Default" ENDINCLINATION="-2030;323;" ID="Arrow_ID_717223261" STARTARROW="None" STARTINCLINATION="-1527;135;"/>
|
||||
<icon BUILTIN="info"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715725538702" ID="ID_321800493" MODIFIED="1715725766650" TEXT="Beschluß">
|
||||
<arrowlink COLOR="#d50a4b" DESTINATION="ID_1843463730" ENDARROW="Default" ENDINCLINATION="-825;-22;" ID="Arrow_ID_1401304077" STARTARROW="None" STARTINCLINATION="-712;193;"/>
|
||||
<node CREATED="1715725550356" ID="ID_1829620474" MODIFIED="1715725571045" TEXT="der AllocationCluster wird „entkernt“"/>
|
||||
<node CREATED="1715725574935" ID="ID_258954925" MODIFIED="1715725594242" TEXT="umschreiben in einen einfachen linearen Allocator"/>
|
||||
<node CREATED="1715725607245" ID="ID_551473047" MODIFIED="1715725616887" TEXT="arbeitet auf verketteten Blöcken"/>
|
||||
<node CREATED="1715725617595" ID="ID_1306733411" MODIFIED="1715725634916" TEXT="diese bekommt man per Delegation an einen Basis-Allocator"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715627195825" ID="ID_40203233" MODIFIED="1715627201745" TEXT="Details festlegen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715625082614" ID="ID_1575150785" MODIFIED="1715625089779" TEXT="SeveralBuilder_test">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
@ -81100,7 +81439,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node CREATED="1715524716035" ID="ID_310789149" MODIFIED="1715524727612" TEXT="wird konkret vom Job aufrgerufen"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823642113" ID="ID_1687015571" MODIFIED="1713823821818" TEXT="TurnoutSystem als Zentral-Element">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1713823642113" ID="ID_1687015571" MODIFIED="1715623490452" TEXT="TurnoutSystem als Zentral-Element">
|
||||
<linktarget COLOR="#970836" DESTINATION="ID_1687015571" ENDARROW="Default" ENDINCLINATION="-844;61;" ID="Arrow_ID_1744365913" SOURCE="ID_1779704166" STARTARROW="None" STARTINCLINATION="-187;-10;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1714997707508" ID="ID_665814613" MODIFIED="1714997710914" TEXT="Analyse">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
|
|
@ -81317,6 +81657,35 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1711549131677" ID="ID_754465017" MODIFIED="1711549140633" TEXT="vorläufig nutzbare Strukturen bereitstellen ">
|
||||
<icon BUILTIN="flag-pink"/>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1682612056884" ID="ID_1219678116" MODIFIED="1715729457579" TEXT="Basis: AllocationCluster/Mem-Manager">
|
||||
<arrowlink COLOR="#816f7b" DESTINATION="ID_688601712" ENDARROW="Default" ENDINCLINATION="95;-321;" ID="Arrow_ID_1440452458" STARTARROW="None" STARTINCLINATION="-521;38;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715725466248" ID="ID_1843463730" LINK="https://issues.lumiera.org/ticket/1365" MODIFIED="1715725766650" TEXT="#1365 establish allocation scheme for render nodes">
|
||||
<linktarget COLOR="#d50a4b" DESTINATION="ID_1843463730" ENDARROW="Default" ENDINCLINATION="-825;-22;" ID="Arrow_ID_1401304077" SOURCE="ID_321800493" STARTARROW="None" STARTINCLINATION="-712;193;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1715725787852" ID="ID_1127426666" MODIFIED="1715729452446" TEXT="neues einfacheres Interface einbauen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1715726296833" ID="ID_320488527" MODIFIED="1715726378902" TEXT="Problem: einzel-Allocator pro Typ">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1715726380325" ID="ID_810607124" MODIFIED="1715726397415" TEXT="führt zu hierarchischer Struktur"/>
|
||||
<node CREATED="1715726517963" ID="ID_1603078940" MODIFIED="1715726538868" TEXT="als nested class mit Zugang zu privaten Methoden"/>
|
||||
</node>
|
||||
<node CREATED="1715727163500" ID="ID_164792121" MODIFIED="1715727175958" TEXT="API">
|
||||
<node CREATED="1715727225764" ID="ID_123722889" MODIFIED="1715727230671" TEXT="getAllocator<TY>"/>
|
||||
<node CREATED="1715727232648" ID="ID_597499360" MODIFIED="1715727238366" TEXT="create"/>
|
||||
<node CREATED="1715727250709" ID="ID_886757416" MODIFIED="1715727252348" TEXT="size"/>
|
||||
<node CREATED="1715728180516" ID="ID_412948320" MODIFIED="1715728191170" TEXT="allot<TY>(cnt)"/>
|
||||
<node CREATED="1715727255639" ID="ID_1782845675" MODIFIED="1715727439713" TEXT="allotMemory(size_t)"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715725837111" ID="ID_1956366876" MODIFIED="1715725864907" TEXT="Basis-Allocator vorsehen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715725950719" ID="ID_1150594476" MODIFIED="1715725971326" TEXT="Testfälle vereinfachen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1711549426546" ID="ID_1360717404" MODIFIED="1711549444466" TEXT="ExitNode ausformulieren">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
|
|
@ -81326,6 +81695,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1711549606378" ID="ID_343085111" MODIFIED="1711549611378" TEXT="Processing-Node">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1715623458395" ID="ID_1779704166" MODIFIED="1715623497615" TEXT="Turnout-System nutzen">
|
||||
<arrowlink COLOR="#970836" DESTINATION="ID_1687015571" ENDARROW="Default" ENDINCLINATION="-844;61;" ID="Arrow_ID_1744365913" STARTARROW="None" STARTINCLINATION="-187;-10;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1711552048459" ID="ID_1144247505" MODIFIED="1711552069425" TEXT="brauche Adapter für den eigentlichen Aufruf">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1711552087622" ID="ID_1064972457" MODIFIED="1711552363214" TEXT="delegieren an die Processing-Function">
|
||||
|
|
@ -81378,7 +81751,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
<node CREATED="1682612009427" ID="ID_1994458742" MODIFIED="1682612053494" TEXT="vermutlich eine referentielle nicht-intrusive Linked-List">
|
||||
<node CREATED="1682612056884" ID="ID_303611553" MODIFIED="1682612072158">
|
||||
<node CREATED="1682612056884" ID="ID_303611553" MODIFIED="1715623658630">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -81387,6 +81760,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<arrowlink COLOR="#816f7b" DESTINATION="ID_688601712" ENDARROW="Default" ENDINCLINATION="95;-321;" ID="Arrow_ID_859179840" STARTARROW="None" STARTINCLINATION="-264;24;"/>
|
||||
</node>
|
||||
<node CREATED="1682612075770" ID="ID_1368353614" MODIFIED="1682612084845" TEXT="ein Eintrag kann in mehreren Instanzen der Liste liegen"/>
|
||||
<node CREATED="1682612094504" ID="ID_250365879" MODIFIED="1682612109226" TEXT="⟹ die umgebaute Liste kann auf einen Schlag aktualisiert werden"/>
|
||||
|
|
@ -81471,12 +81845,19 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1714261516778" ID="ID_1575846856" MODIFIED="1714261522566" TEXT="Control"/>
|
||||
<node CREATED="1714261516778" ID="ID_1575846856" MODIFIED="1715624338108" TEXT="Control"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1680563454868" ID="ID_1187556686" MODIFIED="1680563459014" TEXT="Backbone"/>
|
||||
<node CREATED="1680563460649" ID="ID_127710483" MODIFIED="1680563474067" TEXT="MemManagement"/>
|
||||
<node CREATED="1680563460649" ID="ID_127710483" MODIFIED="1715624384997" TEXT="MemManagement">
|
||||
<arrowlink COLOR="#454059" DESTINATION="ID_1595450559" ENDARROW="Default" ENDINCLINATION="-1036;-77;" ID="Arrow_ID_1704085390" STARTARROW="None" STARTINCLINATION="-161;430;"/>
|
||||
<node CREATED="1715623566743" ID="ID_688601712" MODIFIED="1715624494222" TEXT="AllocationCluster">
|
||||
<linktarget COLOR="#816f7b" DESTINATION="ID_688601712" ENDARROW="Default" ENDINCLINATION="95;-321;" ID="Arrow_ID_859179840" SOURCE="ID_303611553" STARTARROW="None" STARTINCLINATION="-264;24;"/>
|
||||
<linktarget COLOR="#816f7b" DESTINATION="ID_688601712" ENDARROW="Default" ENDINCLINATION="95;-321;" ID="Arrow_ID_1440452458" SOURCE="ID_1219678116" STARTARROW="None" STARTINCLINATION="-521;38;"/>
|
||||
</node>
|
||||
<node CREATED="1715623570769" ID="ID_582193119" MODIFIED="1715623580607" TEXT="Allokations-Verwaltung per Segment"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1512923592590" ID="ID_540019681" MODIFIED="1557498707237" TEXT="Engine">
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1679783052390" ID="ID_1851394144" MODIFIED="1684869799933" TEXT="gründen">
|
||||
|
|
@ -121028,7 +121409,11 @@ std::cout << tmpl.render({"what", "World"}) << s
|
|||
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1711549072833" ID="ID_125061570" MODIFIED="1711549096161" TEXT="Thema: Erweiterbarkeit (Render-Graph)">
|
||||
<icon BUILTIN="hourglass"/>
|
||||
</node>
|
||||
<node CREATED="1711549036030" ID="ID_1875417458" MODIFIED="1711549051408" TEXT="Speicherverwaltung"/>
|
||||
<node CREATED="1711549036030" ID="ID_1875417458" MODIFIED="1711549051408" TEXT="Speicherverwaltung">
|
||||
<node CREATED="1715624289964" ID="ID_1595450559" MODIFIED="1715624384997" TEXT="Speicher mit Fixture-Struktur verbunden">
|
||||
<linktarget COLOR="#454059" DESTINATION="ID_1595450559" ENDARROW="Default" ENDINCLINATION="-1036;-77;" ID="Arrow_ID_1704085390" SOURCE="ID_127710483" STARTARROW="None" STARTINCLINATION="-161;430;"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1681085780230" ID="ID_667166448" MODIFIED="1681085784377" TEXT="Render Toolkit">
|
||||
<node CREATED="1681085789797" ID="ID_435519695" MODIFIED="1681085821901" TEXT="Abstraktionsschicht über Low-Level-Funktionalität"/>
|
||||
|
|
@ -125755,6 +126140,99 @@ std::cout << tmpl.render({"what", "World"}) << s
|
|||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715693174737" ID="ID_152113212" MODIFIED="1715725332461" TEXT="(custom)Allocator">
|
||||
<linktarget COLOR="#4961d5" DESTINATION="ID_152113212" ENDARROW="Default" ENDINCLINATION="-2030;323;" ID="Arrow_ID_717223261" SOURCE="ID_868305899" STARTARROW="None" STARTINCLINATION="-1527;135;"/>
|
||||
<node CREATED="1715693298760" ID="ID_1472333314" MODIFIED="1715693300284" TEXT="Quellen">
|
||||
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1715696253175" ID="ID_267534641" MODIFIED="1715696324289" TEXT="CPP-Referenz">
|
||||
<icon BUILTIN="info"/>
|
||||
<node CREATED="1715694999096" ID="ID_360610134" LINK="https://en.cppreference.com/w/cpp/named_req/Allocator" MODIFIED="1715696312832" TEXT="Allocator (named requirement / Concept)">
|
||||
<icon BUILTIN="back"/>
|
||||
</node>
|
||||
<node CREATED="1715695168872" ID="ID_1006356980" LINK="https://en.cppreference.com/w/cpp/memory/allocator_traits" MODIFIED="1715696294384" TEXT="Allocator-Traits (Basis/Adapter für Allokationen)">
|
||||
<icon BUILTIN="back"/>
|
||||
</node>
|
||||
<node CREATED="1715696264070" ID="ID_1486623180" LINK="https://en.cppreference.com/w/cpp/named_req/AllocatorAwareContainer" MODIFIED="1715696302337" TEXT="Allocator-Aware-Container (definiert die Regeln)">
|
||||
<icon BUILTIN="back"/>
|
||||
</node>
|
||||
<node CREATED="1715700153093" ID="ID_1246505271" LINK="https://en.cppreference.com/w/cpp/memory/allocator" MODIFIED="1715700175680" TEXT="std::allocator">
|
||||
<font NAME="Monospaced" SIZE="12"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715695327590" ID="ID_1357663133" LINK="https://godbolt.org/z/7fnj1rGr9" MODIFIED="1715695362793" TEXT="lauffähiges Beispiel (Godbolt) — Vector mit »mallocator«"/>
|
||||
<node COLOR="#5b280f" CREATED="1715693552823" FOLDED="true" ID="ID_1023319847" LINK="https://www.youtube.com/watch?v=LIb3L4vKZ7U" MODIFIED="1715723921504" TEXT="Alexandrescu CppCon 2015 (video)">
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
<node CREATED="1715723719057" ID="ID_978649638" MODIFIED="1715723916920" TEXT="naja ... nur mäßig hilfreich">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
viel Geplänkel cool-getue; tatsächlich hat er schon einen eigenständigen Gedanken, braucht aber sehr lange, ihn auszuformulieren; und zu den schwierigen praktischen Fragen mit STL-Containern sagt er gar nichts
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="smiley-angry"/>
|
||||
</node>
|
||||
<node CREATED="1715723729266" ID="ID_850299630" MODIFIED="1715723744425" TEXT="er zeigt Design-Schwächen von std::allocator auf (und warum es dazu kam)"/>
|
||||
<node CREATED="1715723745821" ID="ID_1740554357" MODIFIED="1715723779904">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
dann skizziert er alle wesentlichen Standard-Allocator-Patterns als<i>  composable allocators</i>
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715699474963" ID="ID_1114222688" LINK="https://indiegamedev.net/2022/03/27/custom-c20-memory-allocators-for-stl-containers/" MODIFIED="1715699495865" TEXT="Tutorial / Einführungsartikel (2022)"/>
|
||||
<node CREATED="1715701113413" ID="ID_1336731378" LINK="https://github.com/mtrebi/memory-allocators" MODIFIED="1715701155245" TEXT="Standard Allocator-Patterns (Github; Code + Benchmarks)"/>
|
||||
<node CREATED="1715697734801" ID="ID_860671636" MODIFIED="1715697739055" TEXT="Interessant...">
|
||||
<node CREATED="1715697740033" ID="ID_1927640605" LINK="https://stackoverflow.com/a/65649845/444796" MODIFIED="1715697750842" TEXT="Allocator mit »fancy-pointer« nutzen"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715693302202" ID="ID_11875709" MODIFIED="1715693310147" TEXT="Grundlagen">
|
||||
<node CREATED="1715693311183" ID="ID_1432559286" MODIFIED="1715697427063" TEXT="man sollte die std::allocator_traits nutzen (aber nicht erweitern)">
|
||||
<icon BUILTIN="yes"/>
|
||||
<node CREATED="1715723947185" ID="ID_98135787" MODIFIED="1715724017929" TEXT="ab C++23 ist Erweitern sogar verboten">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
Begründung: es ist sinnlos, weil das einzige, was man dabei machen kann, ist Fehler machen. Der Standard ist extrem genau und elaboriert für dieses Thema, und wenn man sich an wirklich alle Vorgaben hält, hat man praktisch keinen Spielraum mehr....
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1715724019592" ID="ID_398818246" MODIFIED="1715724070307" TEXT="sinnvoll ist es den Allocator selber zu schreiben">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
...bei Bedarf kann man dort sogar einige optionale Methoden zusätzlich implementieren, z.B. construct (und das wird dann auch verwendet, anstatt der Standard-Implementierung in den Traits)
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1715697441488" ID="ID_864300058" MODIFIED="1715697501719" TEXT="Custom-Alloc muß nur allocate(size_t) und deallocate(T*, size_t) implementieren (sowie Equality)"/>
|
||||
<node CREATED="1715700840370" ID="ID_461698034" MODIFIED="1715700848437" TEXT="Allocator ist entweder stateless oder stateful">
|
||||
<node CREATED="1715700850389" ID="ID_496751032" MODIFIED="1715700855220" TEXT="ein stateless-Allocator">
|
||||
<node CREATED="1715700855928" ID="ID_774199988" MODIFIED="1715700862415" TEXT="ist default-constructible"/>
|
||||
<node CREATED="1715700862910" ID="ID_1738109434" MODIFIED="1715700875953" TEXT="alle Instanzen sind äquivalent (opeartor ==)"/>
|
||||
<node CREATED="1715700876653" ID="ID_1533428462" MODIFIED="1715700884975" TEXT="kann als Template-Parameter definiert werden"/>
|
||||
</node>
|
||||
<node CREATED="1715700887866" ID="ID_524521259" MODIFIED="1715700900117" TEXT="ein stateful-Allocator muß als ctor-Parameter verdrahtet werden"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1711405781006" FOLDED="true" ID="ID_135618716" LINK="https://en.cppreference.com/w/cpp/language/class_template_argument_deduction#Deduction_for_class_templates" MODIFIED="1711406693840" TEXT="Deduction Guides (CTAD)">
|
||||
<linktarget COLOR="#65354c" DESTINATION="ID_135618716" ENDARROW="Default" ENDINCLINATION="21;-62;" ID="Arrow_ID_696408734" SOURCE="ID_1103669600" STARTARROW="None" STARTINCLINATION="-2;93;"/>
|
||||
<node CREATED="1711405899493" ID="ID_423341464" MODIFIED="1711406049382" STYLE="bubble">
|
||||
|
|
|
|||
Loading…
Reference in a new issue