Nutzt ihr Smartpointer anstatt von jedem Zeiger oder fallen euch Ausnahmen ein?

Ich bin nicht ganz sicher, wann ich weak_ptr und wann shared_ptr benutzen sollte. Was, wenn ich beispielsweise einer Funktion, die irgendwas macht, einen Zeiger übergeben möchte, der in der aufrufenden Funktion als shared_ptr bekannt ist?

Quasi so:

class Test{};

typedef shared_ptr<Test> TestPtrSh;
typedef weak_ptr<Test>   TestPtrWe;

void foo(/* welcher ptr? */ obj)
{
// mache etwas mit obj
}

int main()
{
TestPtrSh obj;
foo(obj);
return 0;
}

shared_ptr hat ja anscheinend schon ein bisschen zu tun, zählt intern Referenzen mit etc. Wenn ich da bei jedem Funktionsaufruf eine Instanz erstellen und danach zerstören lassen würde, wäre das evtl. Overhead, daher macht da für mich der weak_ptr mehr Sinn, oder?

Wie nennt ihr eure typedefs, wenn ihr shared_- und weak_ptr nutzt?

Danke und Grüße!

Hi,

Nutzt ihr Smartpointer anstatt von jedem Zeiger oder fallen euch Ausnahmen ein?

Ich bin nicht ganz sicher, wann ich weak_ptr und wann shared_ptr benutzen sollte. Was, wenn ich beispielsweise einer Funktion, die irgendwas macht, einen Zeiger übergeben möchte, der in der aufrufenden Funktion als shared_ptr bekannt ist?

Quasi so:

class Test{};

typedef shared_ptr<Test> TestPtrSh;
typedef weak_ptr<Test>   TestPtrWe;

void foo(/* welcher ptr? */ obj)
{
// mache etwas mit obj
}

int main()
{
TestPtrSh obj;
foo(obj);
return 0;
}

shared_ptr hat ja anscheinend schon ein bisschen zu tun, zählt intern Referenzen mit etc. Wenn ich da bei jedem Funktionsaufruf eine Instanz erstellen und danach zerstören lassen würde, wäre das evtl. Overhead, daher macht da für mich der weak_ptr mehr Sinn, oder?

Wie nennt ihr eure typedefs, wenn ihr shared_- und weak_ptr nutzt?

Danke und Grüße!

ad 1) Nicht grundsätzlich. Erstens gibt es Fälle, wo sich der Aufwand nicht
lohnt, weil sich z.B. alles innerhalb einer übersichtlichen Funktion abspielt.
Zweitens ist der Overhead zwar meistens vernachlässigbar, aber eben nicht
immer: Ich habe bei geometrischen Algorithmen häufig Millionen kleiner
Objekte, und da spürt man den Einsatz von shared Pointern ganz deutlich in
der Laufzeit.

ad 2) Du verwendest Boost? Ist gut dokumentiert. In Deinem Fall ist ein
shared Pointer gut.

ad 3) Ein Pointer auf ein Triangle heißt bei mir pTriangle. Welche
Pointertype ich dafür einsetze, brauche ich nicht im Namen zu hinterlegen,
das weiß ich für die Fälle, wo ich es mache.

lg

Zu 2)
Kommt ganz auf die Situation an. Wenn du in foo allerdings mit dem Objekt arbeiten willst, kommst du um den shared_ptr nicht herum. Dazu kannst du mal die Dokumentation von Boost lesen.

Zu 3)
Kommt ganz auf die Situation und Bibliothek an. Von Pointer über Iterator bis hin zu Handle ist alles möglich.

Grüssli

Okay. Also vorweg, ich benutze boost. Eigentlich möchte ich ja von der automatischen Deallokation profitieren. Mein Lieblingsfall ist halt die Map auf Zeiger eines Objektes, bei der ich im dtor normalerweise durchiterieren und jedes Element mit delete zerstören müsste. Hier freue ich mich, wenn das automatisch geschieht. Im boost-Beispiel wird für einen STL-Container der shared_ptr für solche Fälle genutzt.

Jetzt weiß ich so viel, dass scoped_ptr non-copyable ist und daher einfach der Inhalt dahinter deleted wird, wenn der Scope aus ist. shared_ptr ist halt copyable. und weak_ptr... Anscheinend nur, wenn man den gerade Mal weiterreichen will, weil Zugriff ja auch nur über shared_ptr-Nutzung geht.

Für mich heißt das aber, dass ich quasi überall, wo ich im ctor einer eigenen Klasse ein Objekt auf dem Heap erstellen und im dtor zerstören würde, jetzt einen Smartptr einsetze. Meistens reicht wohl der scoped_ptr.

Ok, ich laber zu viel, freue mich halt immer, wenn jemand meine Missverständnisse aufdeckt.

Aber dann hier so paar Fragen:

1. Brauche ich shared_ptr für STL-Container, weil die da intern mit rumkopieren könnten oder reicht scoped_ptr?
2. Häufiger Fall ist ja, dass ich eine Klasse habe, die wiederum Klassenobjekte als Attribute hält. Die werden aber nicht selten dynamisch erstellt/gelöscht. Da würde ich dann schon gerne smart_ptr nehmen, weil ansonsten der dtor alles selbst deleten muss. Ist das ein gutes Beispiel für einen Smartptr oder kommt's auch hier drauf an?
3. Wenn Performance keine Rolle spielt, was spricht dann gg. smartptr statt normalen Zeigern? Ich würde eigentlich erstere mit meinem Wissensstand immer bevorzugen wg. Exception-Safety und auch um Tippaufwand (delete ...) zu sparen.

Doku hab ich mir schon durch gelesen, bin durch die Eigenschaften der verschiedenen Pointer aber leider nicht in der Lage zu sagen, wo smartptr ggü. normalem Zeiger besser ist, außer wenn es Mal performacekritisch wird.

Häufiger Fall ist ja, dass ich eine Klasse habe, die wiederum Klassenobjekte als Attribute hält. Die werden aber nicht selten dynamisch erstellt/gelöscht.

Eisflamme schrieb:

3. Wenn Performance keine Rolle spielt, was spricht dann gg. smartptr statt normalen Zeigern? Ich würde eigentlich erstere mit meinem Wissensstand immer bevorzugen wg. Exception-Safety und auch um Tippaufwand (delete ...) zu sparen.

Willst Du schönes C++ betreiben, dann meide smart pointers. Du hattest zum Beispiel Conatiner mit Löschverantwortung genannt, das ist dann Sache des Containers, vielleicht boost::ptr_map, aber boost ist nicht verpflichtend. Objekte in Objekten brauchen gar keine Zeiger (du kennst Initialisiererlisten).
Was Du da anstrebst, ist nicht mehr C++. Wieso nimmst Du nicht Java oder C#? Da klappt alles, was Du Dir heute wünscht, und wirst erst viel später auf Probleme knallen, die Du in C++ nicht hättest. Wenn Du Java/C# innerhalb von C++ simulierst, wirst Du zuerst viele Probleme mit der Simulation haben und viel Lernzeit verlieren, und später, wenn die Simulation einigermaßen läuft, auf die Java/C#-Probleme.

Wann sollte ich denn jetzt was nutzen?

Und ich nutze nicht grundsätzlich Zeiger, wenn nicht nötig, aber einfaches Beispiel: Ich habe einen Renderer, bei welchem man 3D-Modelle zum Rendern "anmelden" kann. Diese geraten dadurch in den Renderzyklus. Wenn ein Objekt nicht mehr in dem Container des Renderers ist, ist es aber nicht erwünscht, dass es zerstört wird, also ist das nicht der typische RAII-Fall.

Und ich nutze nicht grundsätzlich Zeiger, wenn nicht nötig, aber einfaches Beispiel: Ich habe einen Renderer, bei welchem man 3D-Modelle zum Rendern "anmelden" kann. Diese geraten dadurch in den Renderzyklus. Wenn ein Objekt nicht mehr in dem Container des Renderers ist, ist es aber nicht erwünscht, dass es zerstört wird, also ist das nicht der typische RAII-Fall.

Das wäre wohl einer der Fälle, wo rohe Zeiger mal besser als smart pointer sind.

Wann sollte ich denn jetzt was nutzen?

Den Smart Pointer, den ich am meisten benutzt ist wohl scoped_ptr oder selbst std::auto_ptr . Den shared Pointer benutze ich so gut, wie gar nie. Die verwaltenden Container von boost hingegen benutze ich immer mal wieder gerne.
Normale Zeiger benutze ich überall dort, wo ich nichts mit Speicher zu tun habe, die nullbarkeit aber brauche (optionale Funktionalität z.B), ansonsten nehme ich Referenzen.

Und ich nutze nicht grundsätzlich Zeiger, wenn nicht nötig, aber einfaches Beispiel: Ich habe einen Renderer, bei welchem man 3D-Modelle zum Rendern "anmelden" kann. Diese geraten dadurch in den Renderzyklus. Wenn ein Objekt nicht mehr in dem Container des Renderers ist, ist es aber nicht erwünscht, dass es zerstört wird, also ist das nicht der typische RAII-Fall.

Naja. Was bringt es dir, wenn du ein Objekt hast, welches nicht zerstört ist, aber auf das du nicht mehr zugreifen kannst? - Wenn es das wäre, dann hast du ja noch irgendwo einen Zeiger darauf und das Objekt wird nicht zerstört, wenn du es aus dem Container entfernst, sondern der Referenzzähler wird dann einfach um eins nach unten gehen.

//Edit
Obwohl ich eine Möglichkeit für den Renderer mit Smart Pointer genannt habe, unterstütze ich die Meinung von volkard hier keine Smart Pointer einzusetzen. Der Container hat ja nichts mit dem Speicher zu tun. Der Aufrufer muss einfach dafür sorgen, dass das Objekt genug lange lebt, dass es da keine Probleme gibt.

Aber ok, hab den Punkt. Ich überdenke Mal meinen Aufbau nochmal.

Nutzt ihr Smartpointer anstatt von jedem Zeiger oder fallen euch Ausnahmen ein?

Nein, höchstens vor besitzenden Zeigern. Für passive Verweise reichen rohe Zeiger oder Referenzen meistens.

Eisflamme schrieb:

Ich bin nicht ganz sicher, wann ich weak_ptr und wann shared_ptr benutzen sollte. Was, wenn ich beispielsweise einer Funktion, die irgendwas macht, einen Zeiger übergeben möchte, der in der aufrufenden Funktion als shared_ptr bekannt ist?

Zwei Dinge sind mir bisher etwas negativ aufgefallen:

• shared_ptr wird oft überbewertet, und deshalb auch oft aus Faulheit missbraucht. Wie volkard z.B. erwähnt hat, solltest du z.B. lieber Pointer-Container statt Container mit shared_ptr verwenden. Und für lokale RAII-Zeiger nimmst du scoped_ptr . Oder fürs Transferieren von Besitz auto_ptr . Oder für die Übergabe an Funktionen normale Zeiger oder Referenzen, wenn die Quelle gültig bleibt. shared_ptr benötigst du nur, wenn du wirklich geteilte Besitzverhältnisse hast. Und weak_ptr , wenn du Zeiger haben willst, die das Objekt nicht am Leben erhalten.
• Es gibt ein paar bekannte Smart-Pointer (siehe Punkt 1), doch keiner davon hat Kopiersemantik. Merkwürdigerweise scheinen das auch nur wenige Leute zu benötigen, oder die meisten stricken es von Hand nach. Ein Einsatzbereich ist zum Beispiel das Pimpl-Idiom, doch auf der Boost-Seite empfehlen sie dafür tatsächlich shared_ptr .

Nutzt ihr Smartpointer anstatt von jedem Zeiger oder fallen euch Ausnahmen ein?

Ja, bei besitzenden Zeigern, es sei den ich verwende eine Datenstruktur die Zeiger entsprechend behandelt (wie z.B. die Pointercontainer von Boost). Wobei ich nach Möglichkeit die "billigen" Smartpointer wie boost::scoped_ptr verwende, und die "teuren" wie shared_ptr/weak_ptr nur wenn nötig.

Eisflamme schrieb:

Wie nennt ihr eure typedefs, wenn ihr shared_- und weak_ptr nutzt?

Ich benutze kaum typedefs, es sei den die Konstrukte werden wirklich lang (und für ein boost::scoped_ptr<Typ> würde ich noch kein typedef verwenden).

Anderer Fall ist, wenn ich Factory-Zeug nutze (siehe anderer Thread mit "dickem ctor" und so), dann erhalte ich zwangsläufig ja auch einen Zeiger, den ich irgendwo speichern muss.

Dann wäre doch ein scoped_ptr ganz nett. Aber da der normalerweise direkt initialisiert werden muss, was mit meiner Factory nicht geht, würde das dann ja quasi so ablaufen:

class Model;
class Application{
private:
scoped_ptr<Model> model_;
public:
Application();
};

// in Application.cpp:
Application::Application()
{
model_.reset(Factory.CreateModel());
}

Jetzt wirkt es für mich irgendwie etwas unnatürlich, dieses reset. Kann auch Blödsinn sein, aber so würde ich das dann doch machen. Ist das in euren Augen jetzt schlecht, das so zu lösen? Was spricht gegen den scoped_ptr an dieser Stelle und dafür, das model_ selbst im dtor zu deleten?

Ne ganz andere Frage, die jetzt so an das geht, was volkard von wegen Zeiger vermeiden sagt:
Was mache ich denn bei Containern? push_back nutzt bei nem vector ja z.B. einen copy-ctor, oder? Was, wenn ich den für mein Objekt eigentlich sperren lassen möchte, weil er keinen Sinn ergibt?
Oder ich möchte ein performantes Einfügen in den vector gestatten. Wenn ich bei meinem Model die ganzen Modelldaten kopiere, ist das ein extremer Overhead, den ich bei der Arbeit mit Zeigern nicht hätte.

Auch wenn ich jetzt wahrscheinlich wieder C++ im Ganzen missverstehe, freue ich mich auf eure Hilfe.

Ne ganz andere Frage, die jetzt so an das geht, was volkard von wegen Zeiger vermeiden sagt:
Was mache ich denn bei Containern? push_back nutzt bei nem vector ja z.B. einen copy-ctor, oder? Was, wenn ich den für mein Objekt eigentlich sperren lassen möchte, weil er keinen Sinn ergibt?

Heute Zeiger, morgen zunehmend emplace_back. Auf keinen Fall unnötige Standardkonstruktoren oder gar Kopierkonstruktoren machen; dann täten Zeiger weniger weh.

Oder ich möchte ein performantes Einfügen in den vector gestatten. Wenn ich bei meinem Model die ganzen Modelldaten kopiere, ist das ein extremer Overhead, den ich bei der Arbeit mit Zeigern nicht hätte.

Extremes Kopieren von Vector? Naja, manchmal zwei Kopierungen pro Einfügung. Aber vielleicht ruckelig. Große Objekte vielleicht lieber mit verketteten Listen verwalten.
Aber Modelle riechen für mich recht stark nach Zeigern.

Das würdest Du alles mit rohen Zeigern basteln? Oder bieten sich bei Maps dann so diese boost::ptr_map an oder was das ist (ich schaue mir das auch nochmal an demnächst)?

Grüssli

In der Boost-Lib. steht, dass Smartptr fast wie normale Pointer sind, nur automatisch den Speicher freigeben. Also hätte ich die jetzt genommen, wenn es umständlich ist (wie bei ner map, wo man alle Elemente durchgehen muss, um alles zu löschen, na ja).

shared_ptr nutzt jetzt aus, wenn der Zeiger von verschiedenen Leuten genutzt wird ohne dass Verantwortlichkeiten klar sind, das kann in Einzelfällen Mal sein, gut. Aber scoped_ptr dürfte ich dann ja nach deiner Logik nicht verwenden, denn der wird am Ende seines Blocks zerstört. Wenn Block == Klasse, ist der dtor verantwortlich. Wenn Block < Klasse, greift ja wieder die Aussage von irgendwo hier im Thread, dass man die Übersichtlichkeit hat und es daher doch selbst machen kann.

Dann kapier ich nicht, was scoped_ptr und shared_ptr überhaupt sollen.

scoped_ptr ist immer dann gut, wenn man lokal Objekte auf den Heap erzeugen muss (z.B. weil eine Bibliothek nicht mit Stackvariablen klar kommt). Dieser Smartpointer ist bei mir auch der mit Abstand am häufigsten verwendete. shared_ptr/weak_ptr ist genau dann sinnvoll, wenn ein Objekt a) von vielen Anderen gleichzeitig verwendet werden muss, und b) keine zentrale Zerstörung möglich ist.

Sobald die Objekthaltung aber an einer Stelle erfolgen kann (was ich eher für die Regel halte), sollte man shared_ptr nicht verwenden.

Eisflamme schrieb:

In der Boost-Lib. steht, dass Smartptr fast wie normale Pointer sind, nur automatisch den Speicher freigeben.

Im Grundsatz stimmt dies auch, nur kann, je nach Smartpointer, der Verwaltungsaufwand recht hoch sein. Sofern man entweder auf Zeiger verzichten kann, oder wenn es möglich ist, die Erzeugung und Zerstörung an einer Stelle halten, sollte man sich eher auf Objekte, ptr_container oder billige Smartpointer beschränken.

Eisflamme schrieb:

Also hätte ich die jetzt genommen, wenn es umständlich ist (wie bei ner map, wo man alle Elemente durchgehen muss, um alles zu löschen, na ja).

Die prt_container machen eben dies von Haus aus, ohne eine Referenzzählung durchzuführen.

Ich verwende in einem Spiel relativ viele Listen mit Zeigern auf Objekte. Die jeweiligen Klassen übernehmen den Besitz dieser Objekte wie Quads etc. Demnach muss ich die Listen auch jedesmal im Destruktor durchlaufen und die Objekte mit delete löschen, damit es keine Lecks im Speicher gibt. Allerdings sollen andere Klassen oder die Hauptroutine von diesen Objekten jeweils Zeiger erhalten bei Events wie Kollissionen etc.
Mir gehts hauptsächlich darum, dass am Ende des Programnmes oder wenn die Klasse die die Liste führt zerstört wird, der std::vector oder std::list aufgeräumt wird ohne dass ich das manuell machen muss (bzw die Objekte die darin leben).
Welcher Container wäre hier der richtige?
std::auto_ptr()?

rya.

scoped_ptr ist immer dann gut, wenn man lokal Objekte auf den Heap erzeugen muss (z.B. weil eine Bibliothek nicht mit Stackvariablen klar kommt).

1. Lokal heisst innerhalb einer meiner Funktionen? Wo am Anfang das new steht und am Ende das delete? Das ist fuer mich per se aber dann auch kein Argument, es sei denn, man ist sich ueber das Exceptionverhalten der aufgerufenen Bibliotheksfunktion nicht sicher... aber das sollte man imo sowieso immer sein, oder?

2. Das mit den geteilten Verantwortlichkeiten verstehe ich eigentlich auch nicht mehr so ganz. Ich wuerde fast immer dafuer sorgen, dass irgend ein Objekt eben die Hauptverantwortlichkeit traegt, sonst fliegt ein Zeiger ja irgendwie random im Raum rum. Hat jemand dafuer ein Beispiel?

3. Ist es dann ratsam immer die ptr-Container zu nehmen, wenn ich einen Container mit Objektzeigern (wie bei meinem Model) nutze? Oder gibt es auch hier nicht auf den ersten Blick ersichtliche Nachteile?

Snorcher24:
auto_ptr ist ja kein Container. Und ohne deine Frage damit komplett zu beantworten, tut es diese Seite aber zumindest zum Grossteil: http://www.boost.org/doc/libs/1_44_0/libs/ptr_container/doc/ptr_container.html Sieht nett aus.

Ok, das meiste habe ich jetzt verstanden, aber zum scoped_ptr bin ich immer noch nicht sicher:

scoped_ptr ist immer dann gut, wenn man lokal Objekte auf den Heap erzeugen muss (z.B. weil eine Bibliothek nicht mit Stackvariablen klar kommt).

1. Lokal heisst innerhalb einer meiner Funktionen? Wo am Anfang das new steht und am Ende das delete? Das ist fuer mich per se aber dann auch kein Argument, es sei denn, man ist sich ueber das Exceptionverhalten der aufgerufenen Bibliotheksfunktion nicht sicher... aber das sollte man imo sowieso immer sein, oder?

2. Das mit den geteilten Verantwortlichkeiten verstehe ich eigentlich auch nicht mehr so ganz. Ich wuerde fast immer dafuer sorgen, dass irgend ein Objekt eben die Hauptverantwortlichkeit traegt, sonst fliegt ein Zeiger ja irgendwie random im Raum rum. Hat jemand dafuer ein Beispiel?

3. Ist es dann ratsam immer die ptr-Container zu nehmen, wenn ich einen Container mit Objektzeigern (wie bei meinem Model) nutze? Oder gibt es auch hier nicht auf den ersten Blick ersichtliche Nachteile?

Snorcher24:
auto_ptr ist ja kein Container. Und ohne deine Frage damit komplett zu beantworten, tut es diese Seite aber zumindest zum Grossteil: http://www.boost.org/doc/libs/1_44_0/libs/ptr_container/doc/ptr_container.html Sieht nett aus.

Jau, hab mich für boost::ptr_vector entschieden
Danke trotzdem
rya.

Nutzt ihr Smartpointer anstatt von jedem Zeiger oder fallen euch Ausnahmen ein?

Ich nutze fast ausschliesslich Smart-Pointer. Wobei Smart-Pointer jetzt nicht automatisch shared_ptr bedeutet. scoped_ptr ist auch ein Smart-Pointer, sogar der konzeptionell fragwürdige auto_ptr ist ein Smart-Pointer. Interessant dass die Anti-shared_ptr Fraktion das wiedermal total ignoriert hat

Ausnahmen gibt es aber natürlich. z.B. wenn man Zeiger als schnelle Iteratoren über Arrays verwendet. Als Beispiel fallen mir ein: Software-Rendering, Low-Level String-Manipulation, Parser etc.

Wo ich kann versuche ich allerdings ganz auf Zeiger zu verzichten, seien sie nun "smart" oder nicht. z.B. indem ich Referenzen statt Zeigern übergebe.

Ich bin nicht ganz sicher, wann ich weak_ptr und wann shared_ptr benutzen sollte.

weak_ptr verwende ich fast nur um Zyklen aufzubrechen. Ganz ganz selten mal ohne dass es zu Zyklen kommen könnte, wenn z.B. ein Objekt ein anderes kennen soll, aber dessen Zerstörung nicht verhindern (weil das Objekt z.B. viel Resourcen verschlingt). Solche Fälle sind allerdings selten, und lassen sich dann auch oft eleganter lösen.

Was, wenn ich beispielsweise einer Funktion, die irgendwas macht, einen Zeiger übergeben möchte, der in der aufrufenden Funktion als shared_ptr bekannt ist?

Kommt drauf an.
Wenn die Funktion nicht "shared ownership" übernehmen muss, dann musst du keinen shared_ptr übergeben, es reicht eine Referenz.
Wenn die Funktion "shared ownership" übernehmen darf, dann übergibt einen "shared_ptr const&". weak_ptr macht IMO gar keinen Sinn.

shared_ptr hat ja anscheinend schon ein bisschen zu tun, zählt intern Referenzen mit etc. Wenn ich da bei jedem Funktionsaufruf eine Instanz erstellen und danach zerstören lassen würde, wäre das evtl. Overhead, daher macht da für mich der weak_ptr mehr Sinn, oder?

weak_ptr hat gleich viel oder mehr Overhead. Du musst ja den weak_ptr erstmal locken bevor du ihn verwenden kannst. Dabei entsteht ein shared_ptr. Der muss auch irgendwie konstruiert und wieder zerstört werden.
Entweder du übergibst wie schon erwähnt eine Referenz, oder eine (const) Referenz auf den shared_ptr, oder ggf. noch einen rohen Pointer (macht IMO nur Sinn wenn der Zeiger null sein darf).

BTW: der Referenz-Zähler wird - sofern die Boost mit Threading-Support konfiguriert ist - atomar inkrementiert und dekrementiert (-> Interlocked Instructions). 1x shared_ptr kopieren und gleich wieder zerstören kann da gleich mal 100+ Zyklen brauchen, auch wenn alles Inline erweitert wird. Und die meisten Compiler können Interlocked-Aufrufe auch nicht wegoptimieren, was die Sache doppelt schlimm macht

Wie nennt ihr eure typedefs, wenn ihr shared_- und weak_ptr nutzt?

Ich verwende meist gar keine typedefs.
Dort wo sie in unseren Projekten verwendet werden, heissen sie

typederf boost::shared_ptr<Type> TypePtr;

1. Lokal heisst innerhalb einer meiner Funktionen? Wo am Anfang das new steht und am Ende das delete? Das ist fuer mich per se aber dann auch kein Argument, es sei denn, man ist sich ueber das Exceptionverhalten der aufgerufenen Bibliotheksfunktion nicht sicher... aber das sollte man imo sowieso immer sein, oder?

Grundsätzlich gibt es zum scoped_ptr mehr als ein Argument. Das Exceptionverhalten ist eines davon, das andere ist das man unproblematisch ein return in eine Funktion bauen kann. Ich bin ein Favorit davon Funktionen so früh als möglich zu beenden (ist mir lieber als verschachtelte if-Konstrukte).

Eisflamme schrieb:

2. Das mit den geteilten Verantwortlichkeiten verstehe ich eigentlich auch nicht mehr so ganz. Ich wuerde fast immer dafuer sorgen, dass irgend ein Objekt eben die Hauptverantwortlichkeit traegt, sonst fliegt ein Zeiger ja irgendwie random im Raum rum. Hat jemand dafuer ein Beispiel?

Wenn du genau das hast: Ein Objekt trägt die Hauptverantwortung, dann sind shared_ptr fehl am Platz und ptr-Container besser.

Ein Beispiel für den Einsatz von einem shared_ptr könnte z.B. sein, wenn zwei nicht modale Masken auf gleiche Daten zugreifen sollen, aber nicht klar ist, welche zuerst geschlossen wird. Wenn beide die Daten per shared_ptr halten, ist sichergestellt, das die Daten erst mit der letzten gelöscht werden.

Eisflamme schrieb:

3. Ist es dann ratsam immer die ptr-Container zu nehmen, wenn ich einen Container mit Objektzeigern (wie bei meinem Model) nutze? Oder gibt es auch hier nicht auf den ersten Blick ersichtliche Nachteile?

Ich weiß nicht ob das inzwischen geändert wurde (wir haben hier eine ältere Boost-Bibliothek im Einsatz), aber die Schnittstellen der ptr-Container haben sich imho nicht mit allen STL-Konstrukten vertragen (was aber nur selten bei mir zum tragen kam).