Schlanke Smartpointer-Implementierung?
-
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".
-
So, ich habe es einfach mal ausprobiert und in einer bestehenden Applikation ein paar Pointer durch boost::shared_ptr ersetzt. Der resultierende Code (Release-Build, Symbol-stripped) war um gut 20 KBytes größer - was für das bisschen Funktionalität schon mehr als knackig ist. So 1..2 KBytes hätte ich erwartet und die wären auch OK gewesen, aber dieses Ergebnis ist schon sehr überraschend.
-
Ein shared_ptr ist auch nicht bloß "ein bisschen" Funktionalität mehr als ein normaler nackter Pointer. Wenn du glaubst, dass die Größe der Implementierung irgendeine Rolle spielt, dann vergleich einen selbstgeschriebenen shared_pointer oder einen aus einer anderen Bibliothek mit dem von Boost. Du wirst dann keine nennenswerten Unterschiede mehr messen können.
-
RayOfLight schrieb:
So, ich habe es einfach mal ausprobiert und in einer bestehenden Applikation ein paar Pointer durch boost::shared_ptr ersetzt. Der resultierende Code (Release-Build, Symbol-stripped) war um gut 20 KBytes größer - was für das bisschen Funktionalität schon mehr als knackig ist. So 1..2 KBytes hätte ich erwartet und die wären auch OK gewesen, aber dieses Ergebnis ist schon sehr überraschend.
Das ist nun mal der Preis für ein bisschen mehr Komfort, genau wie im richtigem Leben.
-
Burkhi schrieb:
Das ist nun mal der Preis für ein bisschen mehr Komfort, genau wie im richtigem Leben.
Nur genau wie im richtigen Leben sollte auch die Verhältnismäßigkeit gegeben sein: in 4 KBytes bringt man ganze Grafikdemos samt Bildern, Sound und 3D Animationen unter, Boost benötigt 20 KBytes um ein paar Zähler zu bedienen und Speicher freizugeben (und ich rede wirklich von 20 KBytes effektivem Binärcode, der gesamte Executable/Linker-Overhead ist da schon gar nicht mitgezählt).
-
RayOfLight schrieb:
Burkhi schrieb:
Das ist nun mal der Preis für ein bisschen mehr Komfort, genau wie im richtigem Leben.
Nur genau wie im richtigen Leben sollte auch die Verhältnismäßigkeit gegeben sein: in 4 KBytes bringt man ganze Grafikdemos samt Bildern, Sound und 3D Animationen unter, Boost benötigt 20 KBytes um ein paar Zähler zu bedienen und Speicher freizugeben (und ich rede wirklich von 20 KBytes effektivem Binärcode, der gesamte Executable/Linker-Overhead ist da schon gar nicht mitgezählt).
Absolut irrelevant. Der Code wird nicht auf diese Weise optimiert, weil 20K egal sind. Viel wichtiger ist es dass der Code schnell abläuft.
Und das bedeutet, dass der Code länger wird. Man kann ihn natürlich auch kleiner bekommen, nur hat man dann langsameren Code. Und das wollen die meisten Leute nicht, deshalb nimmt man halt die sinnvollste Optimierung.
Und shared_ptr ist ja auch nicht nur einfach ein Zeiger - das ist eine enorm komplexe Angelegenheit - ein bisschen mit einem GC vergleichbar.
