class ara::core::UnsynchronizedPoolResource

Die Deklaration des Kopierkonstruktors als gelöscht (=delete) in ara::core::UnsynchronizedPoolResource gemäß [SWS_CORE_00046] unterbindet jegliche Duplizierung einer Pool-Instanz. Zur Objekterzeugung stehen stattdessen spezifische Konstruktoren zur Verfügung, etwa ohne Argumente [SWS_CORE_00063], mit Angabe einer Upstream-Speicherressource [SWS_CORE_00064], mit PoolOptions [SWS_CORE_00068] oder mit beiden Parametern [SWS_CORE_00067].

Für die Verwendung und das Laufzeitverhalten gelten folgende Rahmenbedingungen:

• Aufruf und Fehlerbehandlung: Ein Kopierversuch wird bereits zur Übersetzungszeit durch den Compiler als Fehler abgewiesen. Allokationsfehler bei der späteren Speichernutzung über do_allocate führen nicht zu Exceptions, sondern liefern nullptr zurück [SWS_CORE_00058], während Freigabefehler in do_deallocate stillschweigend ignoriert werden [SWS_CORE_00059].
• Nebenläufigkeit: Einzelne Speicheroperationen auf der Instanz sind nicht threadsicher deklariert [SWS_CORE_00058], [SWS_CORE_00059]. Interpretation: Das Löschen des Kopierkonstruktors dürfte die exklusive Zuständigkeit für die verwalteten Speicherblöcke sicherstellen und inkonsistente Zustände bei paralleler Nutzung oder vorzeitiger Freigabe via release [SWS_CORE_00065] verhindern. Frage Q-d97dd87dddb2379d (offen)
• Zusammenspiel: Die Restriktion korrespondiert mit dem ebenfalls gelöschten Zuweisungsoperator [SWS_CORE_00047]. Der Destruktor der Klasse ist nicht virtuell ausgeführt [SWS_CORE_00062], während Identitätsprüfungen über do_is_equal [SWS_CORE_00060] vorgenommen werden können.

Der Kopierzuweisungsoperator von ara::core::UnsynchronizedPoolResource ist gemäß [SWS_CORE_00047] explizit als gelöscht (=delete) deklariert. Ein Zuweisen einer Instanz an eine andere ist damit syntaktisch ausgeschlossen und führt bereits zur Übersetzungszeit zu einem Compilerfehler. Zusammen mit dem ebenfalls gelöschten Kopierkonstruktor [SWS_CORE_00046] stellt dies sicher, dass Instanzen der Ressourcenklasse weder kopiert noch durch Zuweisung vervielfältigt werden können. Interpretation: Dies dürfte verhindern, dass interne Speicherblöcke und Verwaltungsinformationen mehrfach referenziert oder fehlerhaft deallokiert werden. Frage Q-75cee08bebc61976 (offen)

Neue Instanzen werden stattdessen über die bereitgestellten Konstruktoren erzeugt, beispielsweise parameterlos über [SWS_CORE_00063], mit Upstream-Ressource über [SWS_CORE_00064] oder unter Angabe von PoolOptions über [SWS_CORE_00067] bzw. [SWS_CORE_00068]. Die verknüpfte Upstream-Ressource kann über [SWS_CORE_00056] und die Konfigurationsoptionen über [SWS_CORE_00057] abgefragt werden. Verwalteter Speicher kann mit [SWS_CORE_00065] explizit freigegeben werden, bevor die Lebensdauer mit dem nicht-virtuellen Destruktor [SWS_CORE_00062] endet.

Da Zuweisungen durch [SWS_CORE_00047] ausgeschlossen sind, müssen Instanzen bei Bedarf per Referenz oder Zeiger übergeben werden. Hierbei ist zu beachten, dass Allokationen über [SWS_CORE_00058] und Deallokationen über [SWS_CORE_00059] als nicht threadsicher spezifiziert sind. Schlägt eine Speicheranforderung fehl, wird keine Exception ausgelöst, sondern nullptr zurückgegeben [SWS_CORE_00058]; Fehler bei der Deallokation werden stillschweigend ignoriert [SWS_CORE_00059].

Verwendung

Die Methode upstream_resource() der Klasse ara::core::UnsynchronizedPoolResource liefert synchron einen Zeiger auf die übergeordnete MemoryResource zurück [SWS_CORE_00056]. Der Aufruf ist parameterlos und als const deklariert. Einbindung und Typdeklarationen erfolgen über die Header-Datei #include "ara/core/memory_resource.h" [SWS_CORE_00056].

Fehlerbehandlung

Die Funktion ist als noexcept sowie exception safe spezifiziert [SWS_CORE_00056]. Sie löst keine Exceptions aus und meldet weder spezifische Fehlercodes noch DET- oder DEM-Ereignisse. Schlägt die vorangehende Initialisierung über Konstruktoren fehl, sind jene teils nicht ausnahmesicher [SWS_CORE_00063], wohingegen die Abfrage selbst stets fehlerfrei bleibt.

Nebenläufigkeit und Einschränkungen

Die Methode upstream_resource() ist explizit als thread-safe eingestuft [SWS_CORE_00056]. Dies steht im Gegensatz zu den internen Allokationsroutinen do_allocate() [SWS_CORE_00058] und do_deallocate() [SWS_CORE_00059], welche als not thread-safe spezifiziert sind. Zudem sind Kopierkonstruktor und Zuweisungsoperator der Klasse gelöscht [SWS_CORE_00046], [SWS_CORE_00047].

Zusammenspiel

Die Methode interagiert eng mit den Konstruktoren von UnsynchronizedPoolResource, welchen optional eine übergeordnete MemoryResource übergeben werden kann [SWS_CORE_00064], [SWS_CORE_00067]. Interpretation: Der zurückgegebene Zeiger dürfte genau auf die bei der Instanziierung festgelegte Instanz von MemoryResource verweisen. Frage Q-aefbc7d0f7d085d1 (offen) Weitere Eigenschaften der Pool-Ressource lassen sich über options() abfragen [SWS_CORE_00057], während allokierter Speicher über release() freigegeben werden kann [SWS_CORE_00065].

Verwendung

Die Elementfunktion options() der Klasse ara::core::UnsynchronizedPoolResource dient der synchronen Abfrage der Speicherpool-Konfiguration [SWS_CORE_00057]. Die Methode ist in #include "ara/core/memory_resource.h" deklariert, erwartet keine Übergabeparameter und gibt eine Instanz des Typs PoolOptions als Wert zurück [SWS_CORE_00057]. Als const-qualifizierte Funktion modifiziert sie das Objekt nicht und verhält sich gemäß der Spezifikation in [mem.res.pool] [SWS_CORE_00057].

Fehlerbehandlung und Ausnahme-Sicherheit

Die Schnittstelle ist als noexcept definiert und garantiert vollständige Ausnahme-Sicherheit (exception safe) [SWS_CORE_00057]. Es werden keine Exceptions geworfen und es existieren keine Fehlerrückgabewerte; der Abruf der Optionen gelingt stets fehlerfrei.

Nebenläufigkeit und Einschränkungen

In der Spezifikation ist options() als threadsicher (thread-safe) ausgewiesen [SWS_CORE_00057]. Dies steht im Gegensatz zu Allokationsfunktionen derselben Klasse wie do_allocate [SWS_CORE_00058] und do_deallocate [SWS_CORE_00059], welche explizit nicht threadsicher sind. Die Methode kann somit nebenläufig zur Zustandsabfrage ausgeführt werden.

Zusammenspiel

Die zurückgegebenen PoolOptions spiegeln vermutlich die Parameter wider, mit denen die Pool-Ressource über entsprechende Konstruktoren parametrisiert wurde [SWS_CORE_00067], [SWS_CORE_00068], oder repräsentieren die Standardoptionen bei Nutzung von Default-Konstruktoren [SWS_CORE_00063], [SWS_CORE_00064]. Frage Q-19fa8ad6e3e6b1c6 (offen) Neben options() steht für die Inspektion auch die Funktion upstream_resource() bereit [SWS_CORE_00056], während Kopieroperationen der Ressource durch gelöschte Operatoren unterbunden sind [SWS_CORE_00046], [SWS_CORE_00047].

Verwendung

Die Methode do_allocate der Klasse ara::core::UnsynchronizedPoolResource allokiert Speicher für die angeforderte Bytegröße (bytes) und Ausrichtung (alignment) [SWS_CORE_00058]. Interpretation: Da die Methode mit geschützter Sichtbarkeit (protected) spezifiziert ist, dürfte sie im regulären Ablauf nicht direkt von Anwendungscode, sondern indirekt über die Allokationsschnittstelle der Basisklasse aufgerufen werden. Frage Q-5a702813496f8071 (offen) Die Deklaration erfolgt über die Header-Datei #include "ara/core/memory_resource.h" [SWS_CORE_00058].

Fehlerbehandlung

Im Unterschied zum Standardverhalten nach [mem.res.pool] ist die Funktion als noexcept deklariert und wirft bei Allokationsfehlern keine Ausnahme wie std::bad_alloc [SWS_CORE_00058]. Stattdessen liefert sie im Misserfolgsfall zwingend nullptr zurück [SWS_CORE_00058]. Aufrufender Code muss das Ergebnis folglich stets explizit auf Nullzeiger prüfen.

Nebenläufigkeit und Einschränkungen

Die Funktion ist als not thread-safe eingestuft [SWS_CORE_00058]. Parallele Aufrufe auf derselben Instanz von UnsynchronizedPoolResource sind ohne externe Synchronisation unzulässig. Kopierkonstruktor und Zuweisungsoperator der Klasse sind gelöscht (delete), sodass Instanzen nicht kopiert werden können ([SWS_CORE_00046], [SWS_CORE_00047]).

Zusammenspiel

Für die Speicherfreigabe existiert das Pendant do_deallocate, das ebenfalls geschützt, noexcept und nicht threadsicher ausgelegt ist sowie Fehler still ignoriert [SWS_CORE_00059]. Der Pool nutzt intern die bei der Instanziierung konfigurierte Upstream-Ressource ([SWS_CORE_00056], [SWS_CORE_00064], [SWS_CORE_00067]). Mit release() kann der vom Pool bezogene Speicher gebündelt freigegeben werden [SWS_CORE_00065].

Verwendung

Die virtuelle Memberfunktion do_deallocate ist als protected im Scope von ara::core::UnsynchronizedPoolResource (Header #include "ara/core/memory_resource.h") deklariert [SWS_CORE_00059]. Sie übernimmt die synchrone Deallokation eines Speicherblocks anhand der übergebenen Parameter p (Zeiger auf den Speicherbereich), bytes (Größe in Byte) und alignment (Ausrichtung). Interpretation: Als geschützte Methode dürfte der Aufruf typischerweise indirekt über die öffentliche Schnittstelle der Speicherressource erfolgen. Frage Q-f4992f515c10ee01 (offen)

Fehlerbehandlung

Gegenüber dem Standardverhalten in [mem.res.pool] weist die Funktion zwei spezifische Abweichungen auf: Sie ist als noexcept deklariert und damit ausnahmesicher [SWS_CORE_00059]. Schlägt die Deallokation fehl, werden Fehler stillschweigend ignoriert (errors will be silently ignored); es existiert weder ein Fehlercode noch eine gesonderte Fehlermeldung.

Nebenläufigkeit und Einschränkungen

Die Operation ist explizit als nicht threadsicher (not thread-safe) ausgewiesen [SWS_CORE_00059]. Werden Speicherbereiche derselben Ressourceninstanz aus mehreren Threads freigegeben, muss der Zugriff zwingend extern synchronisiert werden.

Zusammenspiel

Die Methode komplementiert do_allocate [SWS_CORE_00058], welche ebenfalls als noexcept und nicht threadsicher spezifiziert ist und bei Misserfolg nullptr zurückgibt. Um den gesamten reservierten Speicher des Pools vollständig freizugeben, steht die threadsichere Methode release bereit [SWS_CORE_00065]. Instanzen der Klasse sind nicht kopierbar, da Kopierkonstruktor [SWS_CORE_00046] und Zuweisungsoperator [SWS_CORE_00047] gelöscht sind.

Die geschützte Elementfunktion do_is_equal der Klasse ara::core::UnsynchronizedPoolResource führt den Gleichheitsvergleich für Speicherressourcen gemäß [SWS_CORE_00060] durch. Sie wird über den Header ara/core/memory_resource.h bereitgestellt. Da die Methode die Sichtbarkeit protected aufweist, ist sie für den internen Aufruf über die Basisklasse MemoryResource vorgesehen ([SWS_CORE_00060]). Sie vergleicht synchron die aktuelle Instanz mit einer übergebenen Referenz vom Typ MemoryResource und gibt einen bool-Wert zurück ([SWS_CORE_00060]). Gemäß [mem.res.pool] dürfte der Vergleich typischerweise auf die Identität beider Ressourcen (this == &other) prüfen, da Speicherpools isoliert agieren. Frage Q-679a5e17d2e2903f (offen)

Die Methode ist als noexcept deklariert und besitzt die Spezifikation exception safe ([SWS_CORE_00060]). Sie löst keine Ausnahmen aus und verwendet keine DET- oder DEM-Fehlermeldungen.

In Bezug auf die Nebenläufigkeit ist do_is_equal als thread-safe eingestuft ([SWS_CORE_00060]). Da sie als konstante Elementfunktion ausschließlich lesend arbeitet, kann sie nebenläufig von mehreren Threads aufgerufen werden. Dies steht im Gegensatz zu Allokationsoperationen wie do_allocate ([SWS_CORE_00058]) und do_deallocate ([SWS_CORE_00059]), welche explizit nicht threadsicher sind.

Im Zusammenspiel der Speicherressourcen ist die Klasse weder kopier- noch zuweisbar ([SWS_CORE_00046], [SWS_CORE_00047]). Instanzen können über Konstruktoren wie [SWS_CORE_00063], [SWS_CORE_00064], [SWS_CORE_00067] oder [SWS_CORE_00068] initialisiert werden. Übergeordnete Speicherquellen lassen sich mit upstream_resource() abfragen ([SWS_CORE_00056]), während vor dem Zerstören ([SWS_CORE_00062]) der belegte Speicher mittels release() freigegeben werden kann ([SWS_CORE_00065]).

Der Destruktor ~UnsynchronizedPoolResource() ([SWS_CORE_00062]) beendet die Lebensdauer einer Instanz der Speicherklasse ara::core::UnsynchronizedPoolResource aus dem Header ara/core/memory_resource.h. Der Aufruf erfolgt synchron und ist als noexcept deklariert, womit die Operation ausnahmesicher ist ([SWS_CORE_00062]).

Die Semantik entspricht grundsätzlich der Pool-Nutzung in [mem.res.pool], weist jedoch eine wesentliche Abweichung auf: Der Destruktor ist nicht virtuell ([SWS_CORE_00062]). Interpretation: Aus der Nicht-Virtualität des Destruktors dürfte folgen, dass Instanzen nicht polymorph über einen Basisklassenzeiger auf MemoryResource freigegeben werden dürfen. Frage Q-5578b2bf008b98c5 (offen)

Hinsichtlich des Lebenszyklus und des Zusammenspiels gelten folgende Bedingungen:

• Ressourcenverwaltung: Bei Zerstörung der Instanz wird der verwaltete Speicher freigegeben, analog zur expliziten Freigabe über release() ([SWS_CORE_00065]) in Richtung der übergeordneten Ressource ([SWS_CORE_00056]).
• Nebenläufigkeit: Obwohl der Destruktor selbst als thread-sicher klassifiziert ist ([SWS_CORE_00062]), sind die internen Allokationsroutinen do_allocate ([SWS_CORE_00058]) und do_deallocate ([SWS_CORE_00059]) als nicht thread-sicher ausgewiesen. Der Aufruf des Destruktors darf daher nicht zeitgleich mit Allokationsvorgängen derselben Instanz erfolgen.
• Erzeugung und Kopieren: Instanzen können mit oder ohne Optionen und Upstream-Ressource konstruiert werden ([SWS_CORE_00063], [SWS_CORE_00064], [SWS_CORE_00067], [SWS_CORE_00068]). Kopierkonstruktion und Kopierzuweisung sind gelöscht ([SWS_CORE_00046], [SWS_CORE_00047]).

Der parameterlose Standardkonstruktor [SWS_CORE_00063] initialisiert eine Instanz von ara::core::UnsynchronizedPoolResource gemäß der Semantik aus [mem.res.pool]. Interpretation: Dabei dürften Standard-Pool-Optionen und eine standardmäßige Upstream-Speicherressource herangezogen werden, welche später über [SWS_CORE_00057] und [SWS_CORE_00056] abfragbar sind. Frage Q-d76bae1c251fa516 (offen)

Hinsichtlich des Lebenszyklus und der Verwendung gelten folgende Rahmenbedingungen:

• Kopierschutz und Überladung: Kopierkonstruktor [SWS_CORE_00046] und Zuweisungsoperator [SWS_CORE_00047] sind gelöscht (delete). Neben der parameterlosen Instanziierung stehen überladene Konstruktoren mit expliziten Pool-Optionen oder Upstream-Ressourcen zur Verfügung ([SWS_CORE_00064], [SWS_CORE_00067], [SWS_CORE_00068]).
• Fehlerbehandlung und Exception-Sicherheit: Der Konstruktor ist als nicht ausnahmesicher (not exception safe) deklariert [SWS_CORE_00063]. Im späteren Speicherbetrieb weichen die Speicheroperationen von Standardausnahmen ab: do_allocate liefert im Fehlerfall nullptr anstelle einer Exception [SWS_CORE_00058], während do_deallocate Fehler stillschweigend ignoriert [SWS_CORE_00059].
• Nebenläufigkeit: Der Konstruktoraufruf selbst ist thread-safe [SWS_CORE_00063]. Die späteren Zuweisungs- und Freigabeoperationen der erzeugten Instanz (do_allocate, do_deallocate) sind jedoch explizit nicht threadsicher (not thread-safe) spezifiziert ([SWS_CORE_00058], [SWS_CORE_00059]).
• Ressourcenfreigabe und Destruktion: Belegter Speicher kann über [SWS_CORE_00065] freigegeben werden. Der Destruktor ist noexcept, jedoch nicht virtuell implementiert [SWS_CORE_00062].

Verwendung und Zweck

Der Konstruktor explicit UnsynchronizedPoolResource (MemoryResource *upstream) initialisiert eine Instanz der Klasse ara::core::UnsynchronizedPoolResource aus der Header-Datei #include "ara/core/memory_resource.h" gemäß [mem.res.pool] [SWS_CORE_00064]. Über den Parameter upstream wird die übergeordnete Speicherressource übergeben, welche später über die Methode upstream_resource() abgefragt werden kann [SWS_CORE_00056]. Als Alternativen stehen ein parameterloser Standardkonstruktor [SWS_CORE_00063] sowie Überladungen mit PoolOptions zur Verfügung [SWS_CORE_00067], [SWS_CORE_00068].

Fehlerbehandlung und Ausnahmeverhalten

Die Instanziierung ist als not exception safe spezifiziert [SWS_CORE_00064], sodass während der Konstruktion Ausnahmen auftreten können. Für nachgelagerte Speicherallokationen gelten abweichende Regeln: Die interne Allokationsfunktion do_allocate wirft keine Exception, sondern gibt bei Fehlschlägen nullptr zurück [SWS_CORE_00058], während Fehler bei do_deallocate stillschweigend ignoriert werden [SWS_CORE_00059].

Nebenläufigkeit und Einschränkungen

Der Konstruktoraufruf selbst gilt als thread-safe [SWS_CORE_00064]. Kopieroperationen sind unterbunden, da sowohl der Copy-Konstruktor [SWS_CORE_00046] als auch der Zuweisungsoperator [SWS_CORE_00047] gelöscht sind. Nach der Konstruktion sind die Allokations- und Deallokationsoperationen nicht thread-safe [SWS_CORE_00058], [SWS_CORE_00059]. Zudem ist der Destruktor nicht virtuell deklariert [SWS_CORE_00062]. Belegter Speicher kann über release() vorzeitig freigegeben werden [SWS_CORE_00065]. Interpretation: Da ein nativer Zeiger upstream übergeben wird, dürfte die referenzierte Upstream-Ressource über die gesamte Lebensdauer der Pool-Instanz hinweg gültig bleiben müssen. Frage Q-3e6c23bae834b912 (offen)

Verwendung

Die Elementfunktion release() gehört zum Scope der Klasse ara::core::UnsynchronizedPoolResource und wird über die Header-Datei ara/core/memory_resource.h deklariert [SWS_CORE_00065]. Die Funktion besitzt keine Übergabeparameter und keinen Rückgabewert (void). Ihre funktionale Semantik richtet sich nach dem C++-Standard [mem.res.pool] [SWS_CORE_00065]; der Verweis dürfte bedeuten, dass die Funktion synchron sämtlichen Speicher, der über die Pool-Instanz alloziert wurde, an die vorgelagerte Speicherressource (upstream_resource()) zurückgibt [SWS_CORE_00056]. Frage Q-e0c7e00cde5d5a34 (offen)

Fehlerbehandlung

Die Funktion ist als noexcept sowie als exception safe definiert [SWS_CORE_00065]. Sie löst bei der Ausführung keine Ausnahmen aus. Da die Spezifikation keine spezifischen Fehlercodes oder DET-/DEM-Meldungen aufführt, findet bei Fehlern der Speicherfreigabe keine explizite Fehlerrückmeldung über release() statt.

Nebenläufigkeit und Einschränkungen

Gemäß Spezifikation ist release() als thread-safe klassifiziert [SWS_CORE_00065]. Dies steht im Gegensatz zu den internen Speicherverwaltungsfunktionen der Klasse: Sowohl die Allokation mittels do_allocate [SWS_CORE_00058] als auch die Deallokation über do_deallocate [SWS_CORE_00059] sind explizit als not thread-safe eingestuft.

Zusammenspiel

Die Methode interagiert eng mit weiteren Eigenschaften und Anforderungen der UnsynchronizedPoolResource:

• Speicherressourcen: Sie gibt den Speicher an die konfigurierte Upstream-Ressource zurück [SWS_CORE_00056], ohne dass das Pool-Objekt selbst zerstört werden muss, wie es beim Destruktor ~UnsynchronizedPoolResource() geschieht [SWS_CORE_00062].
• Konfiguration: Das Verhalten und die Chunk-Größen des Pools hängen von den bei der Instanziierung gesetzten Optionen ab [SWS_CORE_00057], [SWS_CORE_00067], [SWS_CORE_00068].
• Kopierschutz: Eine Duplizierung des Pools ist unzulässig, da Copy-Konstruktor [SWS_CORE_00046] und Zuweisungsoperator [SWS_CORE_00047] gelöscht (delete) sind.

Der Konstruktor [SWS_CORE_00067] initialisiert eine Instanz von ara::core::UnsynchronizedPoolResource mit spezifischen Pool-Optionen (opts) und einer übergeordneten Speicherressource (upstream). Der Aufruf erfolgt synchron und ist als noexcept spezifiziert, womit die Objekterzeugung ausnahmesicher ist. Ein Kopieren der Instanz ist ausgeschlossen, da sowohl der Kopierkonstruktor [SWS_CORE_00046] als auch der Zuweisungsoperator [SWS_CORE_00047] gelöscht (=delete) sind.

Die hinterlegten Einstellungen und Upstream-Ressourcen können zur Laufzeit über options() [SWS_CORE_00057] sowie upstream_resource() [SWS_CORE_00056] ausgelesen werden. Als Alternativen stehen ein Standardkonstruktor [SWS_CORE_00063] sowie Überladungen bereit, die ausschließlich upstream [SWS_CORE_00064] oder opts [SWS_CORE_00068] entgegennehmen. Der belegte Speicher kann über release() [SWS_CORE_00065] oder den Destruktor [SWS_CORE_00062] freigegeben werden, wobei der Destruktor abweichend vom Standard nicht virtuell ist.

Hinsichtlich der Nebenläufigkeit ist die Konstruktion selbst als threadsicher deklariert [SWS_CORE_00067]. Die eigentlichen Speicherverwaltungsfunktionen der Instanz – do_allocate [SWS_CORE_00058] und do_deallocate [SWS_CORE_00059] – sind hingegen ausdrücklich nicht threadsicher („not thread-safe“) und erfordern bei parallelem Zugriff externe Schutzmechanismen. Fehler werden dabei ohne Exceptions verarbeitet: Fehlgeschlagene Allokationen liefern nullptr [SWS_CORE_00058], während Deallokationsfehler stillschweigend ignoriert werden [SWS_CORE_00059]. Interpretation: Das übergebene upstream-Objekt muss vermutlich über den gesamten Lebenszyklus des Pools hinweg gültig bleiben. Frage Q-2439ec8f9fb8bb3e (offen)

Der Konstruktor [SWS_CORE_00068] dient der synchronen Initialisierung einer ara::core::UnsynchronizedPoolResource unter Angabe spezifischer Konfigurationsparameter über den Parameter opts (Typ PoolOptions). Das Verhalten richtet sich nach dem Standard [mem.res.pool] aus der Header-Datei ara/core/memory_resource.h. Die übergebenen Einstellungen können nach der Instanziierung mit options() [SWS_CORE_00057] abgerufen werden, während der vorgelagerte Speicherverwalter über upstream_resource() [SWS_CORE_00056] erreichbar ist.

Hinsichtlich der Fehlerbehandlung ist die Funktion als nicht ausnahmesicher („not exception safe“) spezifiziert [SWS_CORE_00068]. Interpretation: Scheitert die interne Bereitstellung von Verwaltungsstrukturen bei der Instanziierung, dürfte eine Ausnahme geworfen werden, womit sich dieser Aufruf von der noexcept-Variante [SWS_CORE_00067] unterscheidet. Frage Q-479a016f4e0ddde7 (offen) Während der Konstruktor selbst als threadsicher („thread-safe“) klassifiziert ist [SWS_CORE_00068], sind spätere Speicheroperationen der resultierenden Instanz wie do_allocate [SWS_CORE_00058] und do_deallocate [SWS_CORE_00059] ausdrücklich nicht threadsicher („not thread-safe“); sie dürfen folglich nicht ungeschützt nebenläufig ausgeführt werden.

Im Zusammenspiel mit dem Lebenszyklus der Klasse ist zu beachten, dass Kopierkonstruktion [SWS_CORE_00046] und Zuweisungsoperator [SWS_CORE_00047] gelöscht (delete) sind. Allokierter Speicher verbleibt im Pool, bis er über release() [SWS_CORE_00065] freigegeben oder das Objekt über den nicht-virtuellen Destruktor [SWS_CORE_00062] zerstört wird.