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?

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.

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.

Wer keine weak_ptr braucht, sollte sich seinen eigenen shared_ptr bauen.

Und wer weak_ptr will, sollte sich den nicht schreiben?

b)

compiled for the iOS simulator in Debug mode

Naja ... wurde mal gemessen, wenn man nur signal2 herausgenommen haette ...

Wer keine weak_ptr braucht, sollte sich seinen eigenen shared_ptr bauen.

Wieso?

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?

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.)

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.

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).

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.

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.

Ähm...vielleicht solltest du dir meinen Link oben erst mal ansehen bevor du sowas öffentlich behauptest...