Schlanke Smartpointer-Implementierung?
-
Hi,
ich bin - aus Platzgründen - auf eine wirklich schlanke Implementierung eines Smartpointers angewiesen. Dabei suche ich eine Variante nach dem Prinzip "der Letzte macht das Licht aus". D.h. der Boost-smart_ptr bietet eigentlich genau das, was ich brauche. Allerdings kann mir da eher keine Rede von "schlank" sein, wenn ich sehe, was da für ein Rattenschwanz von Folgeheadern mit eingezogen wird (die eben nicht nur aus Definitionen bestehen, die sich dann nicht in Codesize niederschlagen würden).
Gibts da irgend wo eine effizientere Implementierung dieser Art von Smartpointer?
-
Beste Lösung: std::shared_ptr .
Zweitbeste Lösung: Implementier ihn halt fix selber. Sollte innerhalb von ein paar Minuten zu machen sein.
-
RayOfLight schrieb:
Hi,
ich bin - aus Platzgründen - auf eine wirklich schlanke Implementierung eines Smartpointers angewiesen. Dabei suche ich eine Variante nach dem Prinzip "der Letzte macht das Licht aus". D.h. der Boost-smart_ptr bietet eigentlich genau das, was ich brauche. Allerdings kann mir da eher keine Rede von "schlank" sein, wenn ich sehe, was da für ein Rattenschwanz von Folgeheadern mit eingezogen wird (die eben nicht nur aus Definitionen bestehen, die sich dann nicht in Codesize niederschlagen würden).
Gibts da irgend wo eine effizientere Implementierung dieser Art von Smartpointer?
shared_ptr aus der Standardlib (ggf. tr1).
-
Aus Neugierde: Wieso spielt bei dir die Größe der Implementierung eine Rolle? Ich kann mir dazu kein Szenario denken.
-
Wenn der etwas höhere Programmieraufwand vertretbar ist, kann intrusive_ptr in Hinblick auf Geschwindigkeit und Codegröße eine gute Wahl sein.
-
Wer keine weak_ptr braucht, sollte sich seinen eigenen shared_ptr bauen.
-
SeppJ schrieb:
Aus Neugierde: Wieso spielt bei dir die Größe der Implementierung eine Rolle? Ich kann mir dazu kein Szenario denken.
Z.B. weil auf dem Zielgerät Speicher nur sehr begrenzt vorhanden ist und der Code deswegen so effizient und schlank wie möglich sein muss.
-
Auf dem Zielgerät ist vom Code nichts mehr übrig. Da ist nur noch das übersetzte Compilat und dessen Größe wird bei allen Smartpointerimplementierungen ziemlich genau gleich sein. Ebenso der zur Laufzeit benötigte Speicher. Die Länge der Implementierung ist bloß Syntaxzucker und bestimmt, wie komfortabel und universell die Implementierung einsetzbar ist.
-
314159265358979 schrieb:
Wer keine weak_ptr braucht, sollte sich seinen eigenen shared_ptr bauen.
Und wer
weak_ptrwill, sollte sich den nicht schreiben?
-
Kann, wenn ein Deleter nicht gebraucht wird. Oder wenn die Anwendung garantiert single-threaded bleibt. Ansonsten fällt mir momentan kein Grund ein, warum man das tun sollte.
-
-
a) Was hat ganz boost wie signal2 mit smart-pointer-Implementierungen zu tun
b)
compiled for the iOS simulator in Debug mode
Naja ... wurde mal gemessen, wenn man nur signal2 herausgenommen haette ...
-
314159265358979 schrieb:
Wer keine weak_ptr braucht, sollte sich seinen eigenen shared_ptr bauen.
Wieso?
-
Weil Joghurt nicht auf Bäumen wächst.
-
Ach, deswegen! *patsch*
314159265358979 schrieb:
Kann, wenn ein Deleter nicht gebraucht wird. Oder wenn die Anwendung garantiert single-threaded bleibt. Ansonsten fällt mir momentan kein Grund ein, warum man das tun sollte.
Was willst du gegenüber shared_ptr einsparen wenn man weak_ptr aber keinen Deleter braucht?
-
Den Deleter.
-
Damit spart man sich die Grösse eines Funktionszeigers im Speicher und einen Funktionsaufruf über diesen Funktionszeiger der dann evtl. komplett wegoptmiert werden kann.
Dort wo shared_ptr zum Einsatz kommen wird beides kein echter Anreiz.
(Den wirklich "bösen" Overhead, nämlich die zusätzliche Allokation für das Counter-Objekt, bekommt man damit aber nicht weg. Das geht nur mit Tricks wie make_shared, und die funktionieren genau so mit Deleter und Weak-Count und allem.)
-
Deleter kannst du meines Wissens komplett in die Tonne kloppen.
-
. o O ( Großes Kino hier ... wartet kurz, ich geh' mir ein Joghurt pflücken
)
-
When I lookup bloat in the lexicon I see "boost".
