shared_ptr - use_count nutzen zum Feintuning.

Finnegan

@john-0 sagte in shared_ptr - use_count nutzen zum Feintuning.:

@Finnegan sagte in shared_ptr - use_count nutzen zum Feintuning.:

Auch brauchst wohl du nicht unbedingt einen polymorphen Allocator wie die in std::pmr (der Hauptgrund für die ist, dass sie zustandsbehaftet sind und pro Instanz eigenen Speicher verwalten können, während die klassischen Allokatoren "global" arbeiten und nur "pro Allocator-Typ" individuellen Speicher haben können). Ein nicht-pmr-Allocator tuts denke ich genau so und käme ohne den (winzigen) Overhead einer polymorphen Klasse aus.

Da bin ich jetzt nicht bei Dir. Auch die „klassischen“ nicht polymorphen Allocatoren können einen Zustand haben und eigenen Speicher pro Instanz verwalten. Der Punkt ist, dass man das über die entsprechenden alloc_traits vorher testen muss, wie sich ein Allokator verhält.

Ein polymorpher Allokator verhält sich pro Instanz unterschiedlich, d.h. er kann nicht nur unterschiedliche Speicherpools verwalten, er kann für jede Instanz eine eigene Strategie verwenden.

Ja, das stimmt. Mein Gedanke war, dass die klassischen Allokatoren keine memory_resource haben, Kopien des Allocator untereinander austauschbar sein müssen (Speicher, der mit einem Allocator geholt wird, muss mit der Kopie freigebbar sein) und das wegen allocator<T>::typename rebind<U>::other auch noch über Typgrenzen hinweg funktionieren muss. Ich hatte das mental so abgespeichert, dass das nur sinnvoll mit einer gobalen Speicher-Ressource geht (wie malloc/free für den Default-Allocator).

Aber natürlich kann man auch einen eigenen Allocator implementieren, der ebenfalls so eine Abstraktion wie memory_resource verwendet, die dann zwischen den Kopien weitergereicht wird. Allerdings ist das mit den pmr-Allokatoren deutlich einfacher, weil die diese Funktionalität bereits haben und man nur die memory_resource implementieren muss. Daher dachte ich fälschlicherweise dass das nur mit denen ginge, aber die Motivation für pmr war wohl vornehmlich sowas hier zu vereinfachen:

std::vector<int, A1> v1;
std::vector<int, A2> v2;
 
v1 = v2; // Inkompatible Typen

Habe ich das richtig verstanden? Die pmr-Allokatoren und Container lösen eigentlich 2 Probleme? Einmal die Kompatibilität von Datenstrukturen, die unterschiedliche Allokatoren verwenden und zum anderen die der gemeinsamen Speicher-Ressource die auch beim Kopieren und bei rebind weitergereicht wird (und die man mit entsprechendem Aufwand auch mit klassichen Allokatoren implementieren kann)?