Die Inkompatibilität stammt von dem Typmerkmal std::uses_allocator, das für die Kombination von std::string und std::pmr::polymorphic_allocator auf false evaluiert. std::string hardcodiert seinen allocator_type als std::allocator<char>, während std::pmr::vector std::pmr::polymorphic_allocator<char> bereitstellt; dies sind verschiedene, nicht verwandte Klassentypen ohne implizite Umwandlungs- oder Vererbungsbeziehung. Wenn der Container Elemente konstruiert, fragt er std::uses_allocator_v<T, Alloc> ab, um zu bestimmen, ob der Allocator als Argument an den Konstruktor übergeben werden soll; da diese Überprüfung fehlschlägt, behandelt der Vektor std::string als allocator-unbemerkt und ruft seinen Standardkonstruktor auf, der intern new und delete unabhängig von der Speicherressource des Vektors verwendet.
static_assert(!std::uses_allocator_v<std::string, std::pmr::polymorphic_allocator<char>>); // std::pmr::vector wird seinen Allocator NICHT an std::string übergeben
Während der Optimierung eines finanziellen Risikomodellierungs-Engines haben wir einen stark frequentierten Weg umgestaltet, um std::pmr::monotonic_buffer_resource zu verwenden, das durch den Stack-Speicher unterstützt wird, um Heap-Inhaltskonkurrenzen zu eliminieren. Wir haben std::pmr::vectorstd::string temp_symbols deklariert in der Erwartung, dass alle temporären Symbolnamen aus dem monotonen Puffer stammen, aber Leistungsprofilierung zeigte unerwartete malloc-Aufrufe innerhalb der std::string-Konstruktoren, was darauf hindeutet, dass die Speicherressource vollständig umgangen wurde.
Wir dachten darüber nach, jede std::string manuell mit einem expliziten std::pmr::polymorphic_allocator zu konstruieren, der an seinen Konstruktor übergeben wird, aber das erforderte die Offenlegung von Allokationsdetails an höherstufige Geschäftslogik und verhinderte die Verwendung bequemer Modifikatoren wie emplace_back. Ein anderer Ansatz bestand darin, einen benutzerdefinierten String-Wrap zu erstellen, der von std::string erbte und einen polymorphen Allocator akzeptierte, aber dies verstieß gegen das Liskov-Ersatzprinzip und führte zu Risiken beim Objekt- slicing während der Container-Neualokation. Letztendlich haben wir std::string durch std::pmr::string (ein Alias für std::basic_string<char, std::char_traits<char>, std::pmr::polymorphic_allocator<char>>) ersetzt, das inhärent allocator_type als die polymorphe Variante deklariert. Dies ermöglichte dem Vektor, seinen Allocator automatisch durch das uses_allocator-Protokoll weiterzugeben, wodurch alle Heap-Allokationen im heißesten Abschnitt eliminiert und die Latenz von Mikrosekunden auf Hunderte von Nanosekunden reduziert wurde.
Wie kann eine benutzerdefinierte Klasse mit std::pmr::polymorphic_allocator kompatibel gemacht werden, wenn sie interne dynamische Allokation durchführt, da es einfach nicht ausreicht, einen Allocator-Parameter in seinen Konstruktor zu akzeptieren?
Eine Klasse muss ihr Allocator-Bewusstsein explizit bekannt geben, indem sie entweder einen öffentlichen Typalias für allocator_type bereitstellt, der in den verwendeten Allocator umwandelbar ist, oder indem sie einen Konstruktor bereitstellt, dessen erster Parameter std::allocator_arg_t und zweiter Parameter der Allocatortyp ist, kombiniert mit der Spezialisierung von std::uses_allocator<ClassName, Alloc>, um von std::true_type abzuleiten. Ohne diese explizite Werbung geht std::pmr::vector davon aus, dass die Klasse allocator-unbemerkt ist, und konstruiert sie über die Standardinitialisierung, wodurch interne Allokationen die polymorphe Speicherressource umgehen.
Warum löst std::allocator_traits<std::pmr::polymorphic_allocator<T>>::rebind_alloc<U> die Inkompatibilität zwischen std::pmr::vector und std::string nicht?
Das Rebinding produziert einen std::pmr::polymorphic_allocator<U>, der inkompatibel bleibt mit std::allocator<U>, da dies unterschiedliche konkrete Typen sind, die keine Umwandlungsbeziehung haben. Der std::uses_allocator-Mechanismus erfordert, dass der allocator_type des Elements derselbe ist oder vom Allocator-Typ des Containers umwandelbar ist, nicht nur auf einen anderen Werttyp umbindbar; da std::string std::allocator hardcodiert, ändert das Binden des Allocators des Containers nicht den erwarteten Allocator-Typ des Elements.
Welches spezifische Lebensdauer-Risiko entsteht bei der Verwendung von std::pmr::monotonic_buffer_resource mit std::pmr::string, und warum ist diese Erkennung schwieriger als bei standardmäßigen Allocatoren?
Da std::pmr::polymorphic_allocator typ-erased ist und einen Zeiger auf eine Basis-std::pmr::memory_resource speichert, kann der Compiler Lebensdauer-Einschränkungen zur Kompilierzeit nicht durchsetzen. Wenn ein std::pmr::string, das auf eine stackbasierte monotonic_buffer_resource verweist, in einen länger lebenden Geltungsbereich verschoben oder kopiert wird, wird der Zeiger auf die Speicherressource schwebend; im Gegensatz zu std::allocator, der typischerweise den globalen Heap verwendet (immer gültig), führt der Zugriff auf die Zeichenfolge nach der Pufferzerstörung zu einem Use-after-free. Statische Analysatoren haben Schwierigkeiten, dies zu erkennen, da die virtuelle do_allocate/do_deallocate-Schnittstelle die Lebensdauer der zugrunde liegenden Ressource vor dem Typsystem verbirgt.