Testen ob shared_ptr gültig ist

314159265358979

hustbaer schrieb:

Und wenn du den shared_ptr nur innerhalb des "if" brauchst, kannst du es auch gleich so schreiben:
if (std::shared_ptr<SysHandle> s = getSysHandle())

Hey, darauf bin ich gar nicht gekommen. Wäre auch die von mir favorisierte Variante, da so der Scope am kleinsten gehalten wird.

unskilled

314159265358979 schrieb:

hustbaer schrieb:
Und wenn du den shared_ptr nur innerhalb des "if" brauchst, kannst du es auch gleich so schreiben:
if (std::shared_ptr<SysHandle> s = getSysHandle())
Hey, darauf bin ich gar nicht gekommen. Wäre auch die von mir favorisierte Variante, da so der Scope am kleinsten gehalten wird.

dann könnte man auch gleich
if(getSysHandle() != nullptr) schreiben?!

bb

314159265358979

Dann hast du ja die Variable nicht mehr.

hustbaer

@unskilled

if (shared_ptr<foo> f = gib_foo())
    f->mach_was();

EDIT: Man kann auch (abstruse) Beispiele finden, wo es sogar ohne Verwendung der shared_ptr Variable nötig ist diese zu erstellen. z.B.:

if (shared_ptr<void> l = lock_the_mighty_lock())
    do_something_that_requires_the_mighty_lock_to_be_locked();

unique_ptr wäre hier vermutlich passender. Bzw. wenn ich mich nicht irre ist sogar unique_lock movable, könnte also auch direkt als Returnwert verwendet werden.
Und mit unique_lock als Returntyp fände ich das nicht mal mehr so abstrus.

unskilled

hustbaer schrieb:

@unskilled

if (shared_ptr<foo> f = gib_foo())
    f->mach_was();

ok, das wusste ich nicht.
aber dann kann man auch scoped_ptr nehmen - und so gar nen rohen pointer...

hustbaer

@unskilled
Siehe EDIT oben.

Wenn die Funktion nen shared_ptr zurückgibt, kannst du keinen scoped_ptr/unique_ptr verwenden. (Es sei denn du kannst die Funktion ändern, und es wird nirgends im Programm ein shared_ptr für das erzeugte Objekt benötigt.)

Und wenn die Funktion z.B. ein neues Objekt erstellt, dann kannst du auch keinen rohen Zeiger verwenden.
Da der zurückgegebene Zeiger ja trotzdem ein shared_ptr ist, und dieser, da er nirgends kopiert wird, das erzeugte Objekt gleich wieder zerstört.

Also das

if (foo* f = create_temporary_foo().get())
    f->mach_was(); // BOOM!

wäre keine gute Idee, da das Objekt vor dem "mach was" bereits wieder zerstört wird.

Nexus

unskilled schrieb:

aber dann kann man auch scoped_ptr nehmen

Nur, wenn gib_foo() den Besitz transferiert, wobei man dann besser unique_ptr nimmt. Üblicher ist bei dieser Verwendung aber, dass man die shared_ptr -Variable erstellt und damit temporär die Lebenszeit des Objekts aufrechterhält.

unskilled schrieb:

und so gar nen rohen pointer...

Und zusätzlich Code sowie Exceptionunsicherheit, oder wie?

unskilled

Nexus schrieb:

unskilled schrieb:

und so gar nen rohen pointer...

Und zusätzlich Code sowie Exceptionunsicherheit, oder wie?

welchen vorteil hat denn der smart pointer in diesem fall?
ist ein delete auf den pointer überhaupt definiert, den wir so bekommen? oder muss man den pointer eh über freeSysPointer() oder ähnliches freigeben?

314159265358979

Hast du überhaupt verstanden, was ein Smartpointer ist?

hustbaer

unskilled schrieb:

Nexus schrieb:

unskilled schrieb:

und so gar nen rohen pointer...

Und zusätzlich Code sowie Exceptionunsicherheit, oder wie?

welchen vorteil hat denn der smart pointer in diesem fall?
ist ein delete auf den pointer überhaupt definiert, den wir so bekommen? oder muss man den pointer eh über freeSysPointer() oder ähnliches freigeben?

Wenn dir eine Funktion einen Smart-Pointer gibt, kannst du davon ausgehen, dass der Pointer smart genug ist, das Objekt korrekt freizugeben.
Wie auch immer die Freigabe auszusehen hat. Das weiss dann der Pointer, du musst dir darüber keine Gedanken mehr machen.

unskilled

ok, war davon ausgegangen, dass getSysHandle eine C-API-Funktion ist und der shared_ptr dort erst aus einem normalen pointer konstruiert wird - aber hat sich so und so erledigt, da der ctor ja eh explicit ist und somit die zeile des TE gar nicht kompilieren würde, wenn meine annahme richtig wäre... sry^^