Ist das hier falsche Benutzung eines shared_ptr?

XSpille

Smarter? schrieb:

Hi!

Ich habe zu diesem Code eine Frage:
Foo* f = new Foo("MyFoo");
shared_ptr<Foo> p1(f);
int c = p1.use_count(); // 1

shared_ptr<Foo>p2(f);
c = p1.use_count(); // 1
c = p2.use_count(); // 1
Das ist eine falsche Benutzung eines shared_ptr, oder?
Wenn p1 und p2 aus dem Scope gehen, wird ja zwei mal versucht f zu löschen, oder?

Ich vermute mal du hast nur einen Pointer als Parameter, aber du möchtest eigentlich an den shared_ptr, der diesen enthält?

#include <iostream>
#include <boost/enable_shared_from_this.hpp>

class Foo : public boost::enable_shared_from_this<Foo>{
};

int main(){
        Foo* f = new Foo();
        boost::shared_ptr<Foo> p1(f);
        int c = p1.use_count(); // 1 
        std::cout << c << std::endl;
        boost::shared_ptr<Foo>p2(f->shared_from_this());
        c = p1.use_count(); // 2 
        std::cout << c << std::endl;

}

Gruß,
XSpille

EOutOfResources

Shade Of Mine schrieb:

Dann erklaer mal deine Aussage bzgl Stack/Heap.

Ich verstehe nicht, was es daran auszusetzen gibt, dass ich das Objekt auf dem Stack statt über einen Smartpointer auf dem Heap anlege.

EOutOfResources

Nachfrager schrieb:

von RAII hältst du dann wohl auch nicht so viel, oder?

Eigentlich doch....
Wieso änderst du deinen Namen bei jedem Post?

XSpille

EOutOfResources schrieb:

Shade Of Mine schrieb:

Dann erklaer mal deine Aussage bzgl Stack/Heap.

Ich verstehe nicht, was es daran auszusetzen gibt, dass ich das Objekt auf dem Stack statt über einen Smartpointer auf dem Heap anlege.

Weil es beim Verlassen des Scopes zerstört wird und man halt 'manchmal' Objekte hat, die länger leben sollen...

EDIT: Ich hoffe er verwendet hier nur Smart-Pointer wegen Code-Reduktion... Zumal er noch threadsafe ist

Shade Of Mine

EOutOfResources schrieb:

Shade Of Mine schrieb:

Dann erklaer mal deine Aussage bzgl Stack/Heap.

Ich verstehe nicht, was es daran auszusetzen gibt, dass ich das Objekt auf dem Stack statt über einen Smartpointer auf dem Heap anlege.

Und Nachts ist es kaelter als draussen.

Wenn du etwas auf den Stack anlegen kannst - dann bedeutet dies, dass du die Lebenszeit des Objektes nicht dynamisch festlegst sondern statisch. Es bedeutet, dass dieses Objekt eine genau definierte, statische, Lebensdauer hat.

Hier verwendet man nie Smartpointer. Es wuerde keinen Sinn machen.

Wenn aber die Lebensdauer dynamisch sein muss, dann muss man das Objekt per new oder aehnlichem anlegen und genau dann sind Smartpointer erstmal erste Wahl.

Und genau das verwirrt hier. Denn Stack Objekte mit Smartpointern vergleichen ist dumm. Das deutet daraufhin dass du etwas grundlegendes nicht verstanden hast. Deshalb die Frage ob du es erklaeren kannst.

PS:
einzeilige Posts zeigen auch nicht wirklich von viel interesse etwas sinnvolles zu dieser diskussion beizutragen...

drakon

Shade Of Mine schrieb:

Es bedeutet, dass dieses Objekt eine genau definierte, ~~statische~~ automatische, Lebensdauer hat.

Ich hätte nicht gemeckert, wenn da ein anderes Wort als statisch stehen würde, aber statische Lebensdauer ist etwas anderes (auch wenn ich annehme, dass du das weisst).

Shade Of Mine

drakon schrieb:

Shade Of Mine schrieb:

Es bedeutet, dass dieses Objekt eine genau definierte, ~~statische~~ automatische, Lebensdauer hat.

Ich hätte nicht gemeckert, wenn da ein anderes Wort als statisch stehen würde, aber statische Lebensdauer ist etwas anderes (auch wenn ich annehme, dass du das weisst).

Statisch im Sinne von Starr (gegenteil von dynamisch). Nicht static.

EOutOfResources schrieb:

Shade Of Mine schrieb:

Dann erklaer mal deine Aussage bzgl Stack/Heap.

Ich verstehe nicht, was es daran auszusetzen gibt, dass ich das Objekt auf dem Stack statt über einen Smartpointer auf dem Heap anlege.

Das eine hat doch nichts mit dem anderen zu tun.
Wie willst du denn einen dynamischen Baum mit Knoten aufbauen, wenn du nur den Stack benutzt? So ein Schwachsinn

EOutOfResources

Omgg schrieb:

Wie willst du denn einen dynamischen Baum mit Knoten aufbauen, wenn du nur den Stack benutzt? So ein Schwachsinn

Wenn man die Klasse selbst schreibt, kann man die Allokation und die Freigabe selbst übernehmen...

Nexus

EOutOfResources schrieb:

Wenn man die Klasse selbst schreibt, kann man die Allokation und die Freigabe selbst übernehmen...

Ich dachte, du würdest was von RAII halten

Sieh es doch ein, Smart-Pointer sind äusserst sinnvoll. Erst recht sobald der Code etwas komplexer wird und mehrere return -Statements oder Exceptions vorkommen können. Stack-Objekte helfen dir auch nicht immer weiter, in solchen Fällen wird der Code ohne Smart-Pointer extrem umständlich.

Shade Of Mine

EOutOfResources schrieb:

Omgg schrieb:

Wie willst du denn einen dynamischen Baum mit Knoten aufbauen, wenn du nur den Stack benutzt? So ein Schwachsinn

Wenn man die Klasse selbst schreibt, kann man die Allokation und die Freigabe selbst übernehmen...

Dennoch kann die Allokation nicht auf dem Stack stattfinden.

PS:
Oder zeig eine implementierung einer add() methode fuer eine beliebige Datenstruktur die ohne dynamische Allokation auskommt.

Nexus

EOutOfResources, im folgenden ein kurzes Beispiel (hier sogar nur mit lokaler Variablengültigkeit).

Deine Aufgabe besteht darin, ohne Smart-Pointer äquivalenten Code zu schreiben. Gehe davon aus, dass jede aufgerufene Funktion der Klassen Base , Derived1 und Derived2 eine Exception werfen kann.

int Fn()
{
    scoped_ptr<Derived1> a(new Derived1);
    scoped_ptr<Base> b;
    if (...)
        b.reset(new Derived1);
    else
        b.reset(new Derived2);

    if (b->MemFn1())
        return 2;

    a->MemFn2();
    if (b->MemFn3())
        return 4;
    else
        return 7;
}

Im Grunde weiß EOutOfResources ja selber, dass seine Haltung Quatsch ist und ein Indiz für Unerfahrenheit ist. Nur aufgrund falschen Stolzes kann er halt jetzt nicht seinen Fehler eingestehen...

Skym0sh0

@nexus:

das ist möglich, ich hab sogar in etwa was vor meinem geistigen auge, aber da kommt redundanter code dazu, und jede einzelne exception wird einzeln per try abgefangen...

life

Nexus schrieb:

EOutOfResources, im folgenden ein kurzes Beispiel (hier sogar nur mit lokaler Variablengültigkeit).

Deine Aufgabe besteht darin, ohne Smart-Pointer äquivalenten Code zu schreiben. Gehe davon aus, dass jede aufgerufene Funktion der Klassen Base , Derived1 und Derived2 eine Exception werfen kann.
int Fn()
{
    scoped_ptr<Derived1> a(new Derived1);
    scoped_ptr<Base> b;
    if (...)
        b.reset(new Derived1);
    else
        b.reset(new Derived2);

    if (b->MemFn1())
        return 2;

    a->MemFn2();
    if (b->MemFn3())
        return 4;
    else
        return 7;
}

int Fn()
{
    Derived1 a;
    if (...) {
        Derived1 b;
        return helper(a,b);        
    }
    else {
        Derived2 b;
        return helper(a,b);
    }
}

int helper(Derived1& a, Base& b) {
    if (b.MemFn1())
        return 2;

    a.MemFn2();
    if (b.MemFn3())
        return 4;
    else
        return 7;
}

Isomorph+ schrieb:

Im Grunde weiß EOutOfResources ja selber, dass seine Haltung Quatsch ist und ein Indiz für Unerfahrenheit ist. Nur aufgrund falschen Stolzes kann er halt jetzt nicht seinen Fehler eingestehen...

Jup, das kommt davon wenn man schreibt ohne nachzudenken.

Nexus

Nicht schlecht, life! Was machst du, wenn wir

if (...)
    b.reset(new Derived1);
else
    b.reset(new Derived2);

ersetzen durch

Base* CreateDerived(); // Funktionsdeklaration
b.reset(CreateDerived());

? Oder falls wir das Derived -Objekt nach der Funktion noch verwenden wollen?

Oder falls wir leserlichen Code wollen?

life

Nexus schrieb:

Nicht schlecht, life! Was machst du, wenn wir
if (...)
    b.reset(new Derived1);
else
    b.reset(new Derived2);
ersetzen durch
Base* CreateDerived(); // Funktionsdeklaration
b.reset(CreateDerived());
? Oder falls wir das Derived -Objekt nach der Funktion noch verwenden wollen?

Ich verwende Smartpointer. Wobei ich bei deinem Beispiel die Lösung ohne Smartpointer sogar fast eleganter finde..

Eisflamme

Smartpointer helfen halt, dass die Speicherverwaltung automatisch erledigt wird. Aber ich finde, die sind kein Muss. Die inflationäre Benutzung davon ist in meinen Augen nicht immer nötig. Es gibt aber viele Fälle, in denen die hilfreich sind.