shared_ptr Zuweisung?

Wurstinator schrieb:

Nachteule schrieb:
Ok.
Aber wieso geht dann das hier schon:
std::tr1::shared_ptr<int> ptr;
ptr = NULL;
Also bei mir kommt auch bei diesem Code dieselbe Fehlermeldung.

Hm, also bei mir gehts (VS 2010).

Kann das vielleicht sonst noch wer testen, der VS 2010 hat?

EOutOfResources

NULL ist eine Integer. Vielleicht hat die Implementierung von VS2010 einen Zuweisungsoperator für Integer implementiert...

Skym0sh0

also bei mir klappt das auch (VS2010)

die methode die aufgerufen wird ist folgende:

shared_ptr(_STD nullptr_t)
		{	// construct with nullptr
		_Resetp((_Ty *)0);
		}

wobei _STD ein define auf ::std:: ist und nullptr_t ein typedef

typedef decltype(__nullptr) nullptr_t;

was heisst dieses decltype ?

EOutOfResources

decltype ist ein Schlüsselwort des nächsten Standards. Es lässt den Programmierer den Typ einer Variable "ermitteln":

int foo;
//Ich will eine neue Instanz des Typen, welcher foo hat
decltype(foo) foo2;

Skym0sh0 schrieb:

also bei mir klappt das auch (VS2010)

die methode die aufgerufen wird ist folgende:
shared_ptr(_STD nullptr_t)
		{	// construct with nullptr
		_Resetp((_Ty *)0);
		}
wobei _STD ein define auf ::std:: ist und nullptr_t ein typedef
typedef decltype(__nullptr) nullptr_t;
was heisst dieses decltype ?

Wieso ist die Implementierung der STL Klassen eigentlich immer so extrem hässlich? Wenn ich einen STL Header aufmache, könnte ich kotzen. Überall total unleserliche, kryptische Namen, Unterstriche ohne Ende. Is das eine Art von Obfuscating

Ok, dann ist ptr = NULL also ein gültiger Weg um einen Null-Shared Pointer zu erzeugen?

Nexus

Nachteule schrieb:

Ok, dann ist ptr = NULL also ein gültiger Weg um einen Null-Shared Pointer zu erzeugen?

Nein. nullptr und NULL ist nicht das Gleiche. Ohnehin würde ich hier reset() aufrufen.

Bashar

Nachteule schrieb:

Wieso ist die Implementierung der STL Klassen eigentlich immer so extrem hässlich? Wenn ich einen STL Header aufmache, könnte ich kotzen. Überall total unleserliche, kryptische Namen, Unterstriche ohne Ende. Is das eine Art von Obfuscating

Zumindest die Unterstriche sind keine Obfuscation, sondern ein Mechanismus, um Namenskollisionen zu vermeiden. Was hält dich beispielsweise davon ab, ein #define Ty zu schreiben? Das ist nicht verboten, würde aber, wenn die Variable im Standardheader auch so heißen würde, höchstwahrscheinlich zu großen Problemen führen. Deshalb gibt es einige Bezeichner, die der Implementation vorbehalten sind, sprich: die der Programmierer nicht verwenden darf. Unter anderem sind das alle Bezeichner, die mit zwei Unterstrichen oder mit Unterstrich-Großbuchstabe anfangen, beispielsweise _Ty, __nullptr, _Resetp. Wer darauf #defines setzt, ist dann selbst schuld.

Ok ich frage am besten mal konkret. Nur damit ich es auch zukünftig richtig mache. Ich habe eine Funktion die einen shared_ptr<Foo> zurückgibt. Es kann nun jedoch sein, dass was schief geht und dann will ich einen NULL shared_ptr liefern.

typedef shared_ptr<Foo> FooPtr;

FooPtr Creator::createXY(params...) {
   FooPtr ptr( new Foo(params) );

   if(ptr->init()) 
      mFooList.push_back(ptr);
   else {
      // Initialisierung von Foo klappte nicht. Hier muss ich das erzeuge Foo
      // löschen und einen "NULL ptr" liefern. 
      ptr = NULL;
   }

return ptr;
}

Ist der Code so richtig? Habe mal etwas debuggt und es scheint (!) zu klappen. Also in der Zeile ptr = NULL wird der Foo Dtor aufgerufen. Also ist der Code korrekt?

Skym0sh0

1.- durch testen/debuggen kannst du nur das vorhandensein von fehlern beweisen, nie aber die abwesenheit von fehlern

2.- nimm shared_ptr<>.reset() ohne parameter. das mit dem = NULL schluckt nur VS2010, da kannst schnell mal probleme bekommen

3.- sonst ist alles ok, sofern du indem vector auch shared_ptr speicherst/speichern willst

Skym0sh0 schrieb:

1.- durch testen/debuggen kannst du nur das vorhandensein von fehlern beweisen, nie aber die abwesenheit von fehlern

2.- nimm shared_ptr<>.reset() ohne parameter. das mit dem = NULL schluckt nur VS2010, da kannst schnell mal probleme bekommen

3.- sonst ist alles ok, sofern du indem vector auch shared_ptr speicherst/speichern willst

Ok, danke!

Nexus

Oder einfach so:

FooPtr ptr(new Foo);
if (ptr->init())
{
    mFooList.push_back(ptr);
    return ptr;
}
else
{
    return FooPtr();
}

Hier sieht man in jedem Fall gleich, was zurückgegeben wird. reset() ist auch nicht nötig.