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?

der shared_ptr zählt mit wie viele zeiger auf ein heap objekt zeigen und der letzte shared_ptr der zerstört wird räumt hinter sich auf.
das funktioniert aber nur wenn du den shared_ptr an einen anderen übergibst und nicht mit rohen zeigern arbeitest

initialisier den ersten shared_ptr direkt mit new Foo() und übergib diesens hared_ptr an alle weiteren shared_ptr die du nutzt

Wobei es möglich ist einen Smartpointer zu implementieren, der hier korrekt freigibt.

aber nicht sinnvoll

aber nicht sinnvoll

Ich halte Smartpointer allgemein nicht für sinnvoll. Ein einzelnes Objekt brauch ich nicht auf dem Heap zu erzeugen.

Shade Of Mine schrieb:

aber nicht sinnvoll

Ich halte Smartpointer allgemein nicht für sinnvoll. Ein einzelnes Objekt brauch ich nicht auf dem Heap zu erzeugen.

wtf?

Warum haeltst du Smartpointer nicht fuer sinnvoll? Ohne Smartpointer kein RAII und ohne RAII kein guter Code...

Ob ein Objekt auf dem Heap erzeugt werden muss hat auch nichts mit der Anzahl der Objekte zu tun...

Mein Punkt war aber: einen Smartpointer zu schreiben der hier korrekt freigibt waere dumm. Zumindest faellt mir keine Situation ein wo er Sinn machen wuerden oder effizient waere.

Shade Of Mine schrieb:

aber nicht sinnvoll

Ich halte Smartpointer allgemein nicht für sinnvoll. Ein einzelnes Objekt brauch ich nicht auf dem Heap zu erzeugen.

fail

warum haeltst du Smartpointer nicht fuer sinnvoll? Ohne Smartpointer kein RAII und ohne RAII kein guter Code...

Einzelne Objekte erzeuge ich auf dem Stack. Verstehe ich dich falsch?

Shade Of Mine schrieb:

warum haeltst du Smartpointer nicht fuer sinnvoll? Ohne Smartpointer kein RAII und ohne RAII kein guter Code...

Einzelne Objekte erzeuge ich auf dem Stack. Verstehe ich dich falsch?

Die Anzahl der Objekte die du brauchst hat idR nichts mit Stack/Heap zu tun. Es sei denn sie wuerden nicht auf den Stack passen... Die Entscheidung ob Stack oder Heap faellt anhand der Lebenserwartung des Objektes.

Shade Of Mine schrieb:

warum haeltst du Smartpointer nicht fuer sinnvoll? Ohne Smartpointer kein RAII und ohne RAII kein guter Code...

Einzelne Objekte erzeuge ich auf dem Stack. Verstehe ich dich falsch?

Und wie machst du das dann beim Einsatz der Polymorphie?

MfG SideWinder

#include <iostream>

class A
{
public:
	virtual void hello_world() { std::cout << "A: Hello World!" << std::endl; }
};

class B : public A
{
public:
	virtual void hello_world() { std::cout << "B: Hello World!" << std::endl; }
};

int main(int argc, char *argv[])
{
	A&& my_object = B();
	my_object.hello_world();
}

http://ideone.com/GKWIp

class X
{
public:
virtual void foo() {std::cout << "Hallo";}
};

class Y : public X
{
public:
virtual void foo() {std::cout << "Halloooo!!";}
};

void callIt(X& ref)
{
    ref.foo();
}

int main()
{
    Y y;
    callIt(y);
}

Edit: Wieso R-Value-Referenz? Eine ganz normale tut doch auch oder wird bei nem auf dem Stack erstellten Objekt nicht zwangsläufig ne Vtable erstellt?

Edit: Wieso R-Value-Referenz? Eine ganz normale tut doch auch oder wird bei nem auf dem Stack erstellten Objekt nicht zwangsläufig ne Vtable erstellt?

Ich wollte nur den blöden Fehler wegen der non-const Referenz auf ein rvalue wegbekommen

Man merkt deutlich, dass EOutOfResources noch im "Hello World" Bereich ist und noch nie was größeres geschrieben hat.

Kann ich nicht bestätigen .

EDIT: Ich nutze generell keine Smartpointer und das kann euch doch egal sein. Ihc hatte deswegen nie Probleme.

MitleserROT schrieb:

Man merkt deutlich, dass EOutOfResources noch im "Hello World" Bereich ist und noch nie was größeres geschrieben hat.

Kann ich nicht bestätigen .

Dann erklaer mal deine Aussage bzgl Stack/Heap.

MitleserROT schrieb:

Man merkt deutlich, dass EOutOfResources noch im "Hello World" Bereich ist und noch nie was größeres geschrieben hat.

Kann ich nicht bestätigen .

Was hast du denn schon größeres geschrieben? von RAII hältst du dann wohl auch nicht so viel, oder?

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

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.

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

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

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

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

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