class ara::core::PolymorphicAllocator

Die Memberfunktion allocate der Klasse ara::core::PolymorphicAllocator dient der synchronen Anforderung von uninitialisiertem Speicher für n Objekte des Typs Tp [SWS_CORE_06547]. Sie orientiert sich an der Funktionalität von [mem.poly.allocator.class], weicht jedoch durch die Deklaration als noexcept und das Attribut [[nodiscard]] gezielt vom C++-Standard ab [SWS_CORE_06547].

Im Fehlerfall wirft allocate keine Ausnahme wie std::bad_alloc, sondern liefert stattdessen einen nullptr zurück [SWS_CORE_06547]. Wegen [[nodiscard]] muss der Aufrufer den Rückgabewert explizit entgegennehmen und auf nullptr prüfen, bevor er den Speicherbereich verwendet [SWS_CORE_06547]. Hinsichtlich der Nebenläufigkeit ist die Funktion als Exception-Safe eingestuft, gilt jedoch als nicht threadsicher (not thread-safe) [SWS_CORE_06547]. Interpretation: Ein synchroner Aufruf über denselben Allokator aus verschiedenen Threads dürfte daher eine externe Absicherung durch den Aufrufer verlangen. Frage Q-b00116faadf930fe (offen)

Das fehlertolerante Verhalten ohne Exceptions korrespondiert direkt mit der Schnittstelle ara::core::MemoryResource::allocate [SWS_CORE_06503], welche ebenfalls als noexcept definiert ist und im Fehlerfall nullptr zurückgibt. Auch vordefinierte Instanzen wie NullMemoryResource [SWS_CORE_06563] nutzen dieses Prinzip und liefern bei Allokationsaufrufen konsequent nullptr. Auf übergeordneter Ebene interagiert dieser Mechanismus mit Containern wie ara::core::Vector [SWS_CORE_01315], deren Zuweisungsoperatoren auf solche Allokationseigenschaften abgestimmt sind.

Verwendung

Die Elementfunktion allocate_bytes der Klasse ara::core::PolymorphicAllocator reserviert Rohspeicher im Umfang von nbytes mit dem vorgegebenen Alignment alignment [SWS_CORE_06549]. Der Standardwert für das Alignment entspricht alignof(std::max_align_t) [SWS_CORE_06549]. Die Funktion wird über den Header ara/core/memory_resource.h eingebunden und synchron ausgeführt [SWS_CORE_06549].

Fehlerbehandlung und Semantik

Im Unterschied zum Standardverhalten nach [mem.poly.allocator.class] weist die Implementierung zwei Abweichungen auf [SWS_CORE_06549]:

• Die Funktion ist als noexcept deklariert und wirft keine Ausnahmen [SWS_CORE_06549].
• Schlägt die Allokation fehl, gibt die Funktion nullptr zurück, anstatt eine Ausnahme auszulösen [SWS_CORE_06549].

Aufgrund des Attributs [[nodiscard]] muss der Rückgabewert vom Aufrufer ausgewertet werden, insbesondere durch eine Prüfung auf nullptr vor dem Zugriff auf den Speicherbereich [SWS_CORE_06549].

Nebenläufigkeit und Einschränkungen

Hinsichtlich der Thread-Sicherheit ist die Methode als not thread-safe spezifiziert [SWS_CORE_06549]. Parallele Aufrufe auf derselben Instanz bedürfen daher vermutlich einer externen Synchronisation [SWS_CORE_06549]. Frage Q-85c74d55563cae38 (offen) Bezüglich der Exception-Sicherheit gilt die Operation als exception safe [SWS_CORE_06549].

Verwendung

Die Template-Elementfunktion allocate_object ist Bestandteil der Klasse ara::core::PolymorphicAllocator und wird über die Header-Datei #include "ara/core/memory_resource.h" bereitgestellt [SWS_CORE_06551]. Sie allokiert synchron Speicher für n Objekte des Typs T, wobei der Parameter n standardmäßig mit dem Wert 1 belegt ist [SWS_CORE_06551]. Das Compiler-Attribut [[nodiscard]] verpflichtet Aufrufer dazu, den zurückgegebenen typisierten Zeiger T* nicht zu ignorieren.

Fehlerbehandlung

Die Spezifikation definiert zwei explizite Abweichungen vom Standard [mem.poly.allocator.class] [SWS_CORE_06551]:

• Keine Exceptions: Die Funktion ist als noexcept deklariert und als ausnahmesicher (exception safe) spezifiziert [SWS_CORE_06551].
• Nullzeiger im Fehlerfall: Schlägt die Speicherallokation fehl, wird keine Exception geworfen, sondern zwingend nullptr zurückgegeben [SWS_CORE_06551].

Der Aufrufer muss den gelieferten Zeiger daher unmittelbar vor einer Weiterverwendung auf nullptr prüfen.

Nebenläufigkeit und Einschränkungen

Die Operation ist als nicht threadsicher (not thread-safe) spezifiziert [SWS_CORE_06551]. Bei nebenläufiger Verwendung derselben Allokator-Instanz dürfte eine externe Synchronisation erforderlich sein, um Datenrennen zu vermeiden. Zudem reserviert die Funktion reinen Speicher (Interpretation: die Konstruktion von Objekten im reservierten Speicher obliegt nachgelagerten Mechanismen). Frage Q-c41df2caaeb4c503 (offen)

Die Template-Funktion construct der Klasse ara::core::PolymorphicAllocator ([SWS_CORE_06555]) dient dem synchronen Erzeugen eines Objekts vom Typ T an der übergebenen Speicheradresse p unter Weiterleitung der Argumente args.... Sie ist über den Header ara/core/memory_resource.h definiert und folgt im Wesentlichen den Vorgaben aus [mem.poly.allocator.class].

Eine explizite Abweichung vom C++-Standard betrifft die Ausnahmebehandlung: Gemäß [SWS_CORE_06555] ist die Funktion bedingt als noexcept deklariert, abhängig davon, ob std::is_nothrow_constructible<T, Args...>::value zutrifft. Die Spezifikation weist ihr damit das Attribut conditionally exception safe zu. Interpretation: Sofern T nicht ausnahmefrei konstruierbar ist, dürften etwaige Konstruktor-Ausnahmen ungehindert an den Aufrufer propagiert werden, da keine internen Fehlercodes oder gesonderten Abfangmechanismen definiert sind. Frage Q-ad77510f396e59ae (offen)

Hinsichtlich Nebenläufigkeit und Randbedingungen ist construct als nicht threadsicher (not thread-safe) spezifiziert ([SWS_CORE_06555]). Bei parallelen Zugriffen auf dieselbe Allocator-Instanz oder denselben Speicherbereich ist daher eine externe Synchronisation im Aufrufkontext zwingend erforderlich.

Das Architekturmuster einer typabhängigen noexcept-Deklaration entspricht den Konventionen in ara::core, wie sie unter anderem auch bei den Konstruktoren von ara::core::Result eingesetzt werden ([SWS_CORE_00725], [SWS_CORE_00726]).

Verwendung

Die Elementfunktion deallocate der Klasse ara::core::PolymorphicAllocator gibt zuvor allozierten Speicher für n Objekte des Typs Tp ab der Adresse p frei [SWS_CORE_06548]. Die Deklaration erfolgt über den Header ara/core/memory_resource.h [SWS_CORE_06548]. Die Funktion folgt grundsätzlich der Semantik des Standard-C++-Allocators gemäß [mem.poly.allocator.class], weist jedoch zwei spezifische Abweichungen auf [SWS_CORE_06548].

Fehlerbehandlung und Exception-Sicherheit

Als wesentliche Abweichung ist die Operation als noexcept deklariert und als ausnahmesicher (exception safe) spezifiziert [SWS_CORE_06548]. Schlägt die Freigabe des Speichers fehl, werden auftretende Fehler stillschweigend ignoriert (silently ignored), sodass weder Ausnahmen geworfen noch explizite Fehlercodes zurückgemeldet werden [SWS_CORE_06548].

Nebenläufigkeit und Zusammenspiel

Hinsichtlich des Aufrufkontexts ist deallocate als nicht threadsicher (not thread-safe) eingestuft [SWS_CORE_06548]. Im Speicherverwaltungskonzept korrespondiert diese Funktion mit der Methode deallocate der zugrundeliegenden Basisklasse ara::core::MemoryResource [SWS_CORE_06504], für die dieselben Abweichungen bezüglich noexcept und stillschweigender Fehlerbehandlung gelten.

Die Funktion deallocate_bytes der Klasse ara::core::PolymorphicAllocator dient der Freigabe eines zuvor allokierten Speicherbereichs gemäß [SWS_CORE_06550]. Sie wird über den Header ara/core/memory_resource.h bereitgestellt und orientiert sich grundsätzlich an der Semantik aus [mem.poly.allocator.class].

Der Aufruf erfolgt synchron und erwartet folgende Parameter gemäß [SWS_CORE_06550]:

• p: Zeiger (void*) auf den freizugebenden Speicherbereich.
• nbytes: Größe des freizugebenden Speichers in Bytes (std::size_t).
• alignment: Gewünschtes Alignment (Standardwert alignof(std::max_align_t)).

Hinsichtlich des Fehlerverhaltens weist die Implementierung spezifische Abweichungen zum Standard auf: Die Funktion ist als noexcept deklariert und gilt als ausnahmesicher (exception safe). Schlägt die Freigabe fehl, werden auftretende Fehler stillschweigend ignoriert (silently ignored) laut [SWS_CORE_06550]. Es werden keine Exceptions geworfen und keine Rückgabewerte bereitgestellt.

In Bezug auf Nebenläufigkeit und Einschränkungen ist die Funktion explizit als nicht threadsicher (not thread-safe) spezifiziert [SWS_CORE_06550]. Ein nebenläufiger Zugriff auf dieselbe Allokator-Instanz ohne externe Synchronisation dürfte daher zu undefiniertem Verhalten führen. Frage Q-33c80e3bb50ed64f (offen)

Die Template-Funktion deallocate_object der Klasse ara::core::PolymorphicAllocator dient der Freigabe von zuvor reserviertem Objektspeicher [SWS_CORE_06552]. Sie orientiert sich an der entsprechenden C++-Standardverwendung gemäß [mem.poly.allocator.class], weist jedoch spezifische Abweichungen auf [SWS_CORE_06552].

Hinsichtlich Parametern und Aufrufkontext gelten folgende Eigenschaften [SWS_CORE_06552]:

• Signatur: template <class T> void deallocate_object (T *p, std::size_t n=1) noexcept; [SWS_CORE_06552].
• Header: Die Funktion ist über #include "ara/core/memory_resource.h" verfügbar [SWS_CORE_06552].
• Rückgabewert: Die Operation liefert keinen Rückgabewert (void) [SWS_CORE_06552].
• Nullzeiger-Verhalten: Als explizite Abweichung ist spezifiziert, dass die Funktion bei Übergabe von nullptr greift bzw. Nullzeiger unterstützt („Function is nullptr“) [SWS_CORE_06552].

Bezüglich der Fehlerbehandlung ist die Funktion als noexcept deklariert und gilt als ausnahmesicher (exception safe) [SWS_CORE_06552]. Schlägt eine Deallokation fehl, werden auftretende Fehler stillschweigend ignoriert („errors will be silently ignored“), sodass keine Ausnahmen nach außen propagiert werden [SWS_CORE_06552].

Als wesentliche Einschränkung ist deallocate_object als nicht threadsicher (not thread-safe) klassifiziert [SWS_CORE_06552]. Bei parallelen Zugriffen auf dieselbe Allocator-Instanz aus mehreren Threads müssen Aufrufe daher durch externe Synchronisationsmechanismen abgesichert werden.

Die Elementfunktion delete_object der Klasse ara::core::PolymorphicAllocator dient gemäß [SWS_CORE_06554] der Zerstörung und Freigabe eines Objekts vom Typ T, auf das der übergebene Zeiger p verweist. Die Funktion wird über die Header-Datei #include "ara/core/memory_resource.h" bereitgestellt und folgt dem Verhalten aus [mem.poly.allocator.class] mit spezifischen Abweichungen.

Hinsichtlich des Aufrufkontexts und der Semantik gelten folgende Eigenschaften:

• Rückgabewert und Ausnahmen: Die Funktion besitzt keinen Rückgabewert (void). Sie ist bedingt ausnahmesicher (conditionally noexcept) mit der Spezifikation noexcept(std::is_nothrow_destructible<T>::value), wirft also keine Ausnahmen, sofern der Destruktor von T als nicht-werfend deklariert ist [SWS_CORE_06554].
• Fehlerbehandlung: Schlägt die Operation fehl, werden aufgetretene Fehler stillschweigend ignoriert (errors will be silently ignored) [SWS_CORE_06554]. Interpretation: Aufrufer erhalten somit im Fehlerfall weder eine Fehlermeldung noch einen Fehlercode oder eine Exception. Frage Q-9393b0f68a055e4b (offen)
• Thread-Sicherheit: Die Operation ist als nicht threadsicher (not thread-safe) spezifiziert [SWS_CORE_06554]. Bei nebenläufiger Verwendung desselben Allokators über mehrere Threads hinweg obliegt die Synchronisation dem Aufrufer.

Verwendung

Die Template-Elementfunktion destroy der Klasse ara::core::PolymorphicAllocator ([SWS_CORE_06556]) dient dem Destruieren eines Objekts vom Typ T, auf das der Zeiger p verweist. Die Funktion ist im Header ara/core/memory_resource.h deklariert und folgt grundsätzlich dem standardisierten Verhalten aus [mem.poly.allocator.class] ([SWS_CORE_06556]). Der Methodenaufruf liefert keinen Rückgabewert und wird synchron im Kontext des aufrufenden Threads ausgeführt. Interpretation: Hierbei dürfte vorausgesetzt werden, dass p auf ein gültiges, zuvor instanziiertes Objekt verweist. Frage Q-a4faf7034eb683dd (offen)

Fehlerbehandlung und Exception-Sicherheit

Bezüglich der Fehlerbehandlung ist die Funktion als bedingt ausnahmesicher (conditionally exception safe) klassifiziert ([SWS_CORE_06556]). Als spezifische Abweichung von der Standardanforderung [mem.poly.allocator.class] ist destroy bedingt mit noexcept(std::is_nothrow_destructible<T>::value) deklariert ([SWS_CORE_06556]). Sofern der Destruktor des übergebenen Typs T keine Ausnahmen wirft, gilt die Ausnahmefreiheit für den gesamten Aufruf; andernfalls können aus dem Destruktor resultierende Exceptions entweichen.

Nebenläufigkeit und Einschränkungen

Hinsichtlich des Nebenläufigkeitsverhaltens ist destroy als nicht threadsicher (not thread-safe) spezifiziert ([SWS_CORE_06556]). Wenn mehrere Threads gleichzeitig auf dieselbe Instanz von ara::core::PolymorphicAllocator oder auf das zu zerstörende Objekt zugreifen, müssen geeignete externe Synchronisationsmechanismen etabliert werden.

Die Template-Elementfunktion new_object der Klasse ara::core::PolymorphicAllocator (definiert in #include "ara/core/memory_resource.h") allokiert synchron Speicher und konstruiert ein Objekt des Typs T mit den übergebenen Konstruktorargumenten ctor_args [SWS_CORE_06553].

Die Verwendung unterliegt folgenden Festlegungen und Abweichungen vom Standard [mem.poly.allocator.class] [SWS_CORE_06553]:

• Aufruf und Rückgabewert: Bei erfolgreicher Objekterzeugung wird ein typisierter Zeiger T* auf die neue Instanz zurückgeliefert. Das Attribut [[nodiscard]] verpflichtet Aufrufer dazu, den Rückgabewert auszuwerten.
• Fehlerbehandlung: Im Misserfolgsfall wird abweichend von [mem.poly.allocator.class] keine Exception ausgelöst, sondern nullptr zurückgegeben. Der Aufrufer muss den resultierenden Zeiger daher vor dem Zugriff zwingend auf nullptr prüfen.
• Ausnahmesicherheit: Die Funktion ist als bedingt ausnahmesicher (conditionally exception safe) spezifiziert. Sie ist genau dann noexcept, wenn die Objekterzeugung selbst garantiert keine Ausnahme wirft (noexcept(std::is_nothrow_constructible<T, CtorArgs...>::value)).
• Nebenläufigkeit: Die Funktion ist als nicht threadsicher (not thread-safe) deklariert. Interpretation: Bei gleichzeitigem Zugriff auf dieselbe Instanz von ara::core::PolymorphicAllocator dürfte der Aufrufer für eine geeignete externe Synchronisation zuständig sein. Frage Q-3d0ecfe34187c91e (offen)

Die Methode resource ist eine konstante Elementfunktion der Klasse ara::core::PolymorphicAllocator aus der Header-Datei #include "ara/core/memory_resource.h" [SWS_CORE_06557]. Sie dient gemäß der Spezifikationsreferenz auf [mem.poly.allocator.class] dem synchronen Abruf der zugeordneten Speicherressource [SWS_CORE_06557].

Verwendung und Signatur

Die Funktionssignatur lautet MemoryResource * resource () const noexcept; [SWS_CORE_06557]. Der Aufruf erfolgt parameterlos und synchron auf einer Instanz von ara::core::PolymorphicAllocator. Als Rückgabewert liefert die Funktion einen Zeiger vom Typ MemoryResource* [SWS_CORE_06557]. Interpretation: Der zurückgegebene Zeiger dürfte direkt auf die konkrete Speicherressource verweisen, die der Allokator für Speicheroperationen verwendet. Frage Q-392683a38a4e490b (offen)

Fehlerbehandlung und Nebenläufigkeit

• Ausnahmesicherheit: Die Funktion ist als noexcept deklariert und als exception safe eingestuft [SWS_CORE_06557]. Sie wirft keine Exceptions, und es sind keine spezifischen Fehlercodes definiert.
• Thread-Sicherheit: Die Spezifikation weist die Methode explizit als thread-safe aus [SWS_CORE_06557]. Durch die Qualifizierung als const ist der nebenläufige Lesezugriff über mehrere Threads hinweg sicher.

Zusammenspiel

Im Modul core stellt resource die Schnittstelle bereit, um die von ara::core::PolymorphicAllocator gekapselte MemoryResource abzufragen und deren Operationen anzusprechen [SWS_CORE_06557].

Verwendung

Die Elementfunktion select_on_container_copy_construction gehört zum Scope der Klasse ara::core::PolymorphicAllocator und wird über die Header-Datei #include "ara/core/memory_resource.h" deklariert ([SWS_CORE_06573]). Sie wird synchron aufgerufen, um bei der Kopierkonstruktion eines Containers eine neue Instanz von PolymorphicAllocator zu erzeugen ([SWS_CORE_06573]). Das funktionale Verhalten folgt dabei der Vorgabe [mem.poly.allocator.class] ([SWS_CORE_06573]). Interpretation: Der resultierende Allokator dürfte standardkonstruiert sein und somit auf die standardmäßige Speicherressource zurückgreifen, anstatt die Speicherressource des Quell-Containers zwingend zu kopieren. Frage Q-134ed967dc22e133 (offen)

Fehlerbehandlung und Exception-Sicherheit

Eine zentrale Abweichung von der allgemeinen C++-Spezifikation besteht darin, dass die Funktion in AUTOSAR explizit als noexcept deklariert ist ([SWS_CORE_06573]). Die Ausführung ist als ausnahmesicher (exception safe) definiert ([SWS_CORE_06573]). Spezifische Fehlercodes, Rückgabewerte zur Fehlerindikation oder Meldungen an DET oder DEM sind für diese Schnittstelle nicht vorgesehen, da der Aufruf fehlerfrei garantiert terminiert.

Nebenläufigkeit und Einschränkungen

Laut Spezifikation ist die Funktion als not thread-safe klassifiziert ([SWS_CORE_06573]). Dies bedeutet, dass gleichzeitige Aufrufe auf derselben PolymorphicAllocator-Instanz aus mehreren Threads ohne externe Synchronisation zu Datenrennen führen können. Vor dem Kopieren eines Containers in nebenläufigen Umgebungen muss der Zugriff auf das Allokator-Objekt durch den Anwender geschützt werden.