allocator und list-implementierung
-
Shade Of Mine schrieb:
per rebind.
danke
geht das nur mit allocatoren? da würden mir direkt eine menge anderer anwendungszwecke für eine solche funktion einfallen...
-
gamer8o4 schrieb:
geht das nur mit allocatoren? da würden mir direkt eine menge anderer anwendungszwecke für eine solche funktion einfallen...
Beispiel?
-
gamer8o4 schrieb:
Shade Of Mine schrieb:
per rebind.
danke
geht das nur mit allocatoren? da würden mir direkt eine menge anderer anwendungszwecke für eine solche funktion einfallen...
Die Technik funktioniert ueberall - aber die Klasse muss dieses Interface halt anbieten. Allocatoren haben halt rebind als Member - einen vector<int> auf vector<double> kann man so leider nicht umbiegen - dazu muss das rebind leider immer auf den Typen spezialisiert sein.
Das Problem ist naemlich, dass ein vector<int> in wirklichkeit ja ein vector<int, allocator<int> > ist, oder noch schlimmer vielleicht sogar ein vector<int, allocator<int>, foo, bar, baz> - um hier nun int in float zu tauschen, muss man natuerlich alle Parameter kennen. Deshalb gibt es kein generisches Rebind fuer alle Typen.
-
super antwort, danke
-
oh, eine letzte frage noch, wie wird dann ein allocator vom typ std::allocator<T>
intern zurückgegeben, wenn doch eigentlich intern nur ein std::allocator<node> existiert?
Man kann doch wohl keine objecte mit rebind verändern, oder?
-
gamer8o4 schrieb:
oh, eine letzte frage noch, wie wird dann ein allocator vom typ std::allocator<T>
intern zurückgegeben, wenn doch eigentlich intern nur ein std::allocator<node> existiert?
Man kann doch wohl keine objecte mit rebind verändern, oder?Nein. Deswegen ist ein zweites, unbenutztes Objekt vom Ursprünglichen Allokator-Typ zu halten und als Kopie zurückzugeben.
Diese Diskussion wurde schon in Swordfishs Thread geführt. http://www.c-plusplus.net/forum/317842-30
-
.
-
ich habs jetzt einfach so gelöst, dass ich intern einen std::allocator<int> habe, den aber nur über Al::rebind<Node>::other(this->Myal) aufrufe
so kann ich den gewünschten typ zurückgeben und trotzdem Node-objecte erstellen.
-
Wenn ich mich mal einmischen dürfte, ich finde dass die Frage nicht so sinnlos ist, schließlich sollte man bei seinen Bestrebungen die Tatsache, dass C++11 stateful allocators erlaubt nicht auslassen. Desweiteren, eigentlich sollte ein allocator, sollte er den Anforderungen für Allokatoren entsprechen, kopierbar sein, das heißt man kann einen allocator eines Typs konstruieren mit dem allocator eines anderen Typs, vorrausgesetzt es handelt sich um denselben allocator (z.B. std::allocator<int> und std::allocator<float>)
PS: Du speicherst also den alten allocator, und konstruierst damit ständig einen neuen, der dafür geeignet ist. Spricht etwas dagegen intern einen allocator<node<int> > zu speichern und wann immer get_allocator aufgerufen wird, einen allocator<int> von dem internen allocator zu konstruieren? So oft wird das ja nicht passieren, im Vergleich zu einer allocation
-
Wenn geht sollten mMn. immer alle benötigten Allokatoren als Member abgelegt sein.
Wobei das bei klassischen Containern eh nur einige wenige sein sollten.Blöd wird's z.B. bei nem Container der erlaubt abgeleitete Klassen "by value" reinzustecken. Mit ner verketteten Liste ginge das z.B. recht einfach. Da dort
push_backaber ein Template ist, und mit beliebig vielen Typen funktioniert, kann man natürlich nicht mehr einfach alle Allokatoren aufheben. Bzw. man könnte schon, aber dann müsste man die wieder in irgend einem Container halten, und ob der Lookup dann billiger ist als den Allokator "just in time" zu erzeugen ist die Frage...
