Deep Copy eines std::shared_ptr

Vielen Dank für die zahlreichen Antworten!

Den Unterschied zwischen emplace_back und push_back hatte ich offensichtlich verstanden. Eure Antworten bestätigen genau das, was ich erwartet hatte.

Die Vorteile von make_shared muss ich mir allerdings nochmal vergegenwärtigen. Falls jemand einen Tipp hat, wo es dazu etwas nachzulesen gibt, dann gerne her damit.

...habe selbst Literatur gefunden: Scott Meyers beschreibt es sehr gut, denke ich.

Columbo

camper schrieb:

container.emplace_back(new MyClass(*sharedPtr));
Ist böse, da nicht exceptionsicher.

Und welche (nicht kritische) Exception soll geworfen werden, nachdem new ausgewertet aber bevor das interne shared_ptr -Objekt konstruiert wurde?

camper

Arcoth schrieb:

camper schrieb:
container.emplace_back(new MyClass(*sharedPtr));
Ist böse, da nicht exceptionsicher.
Und welche (nicht kritische) Exception soll geworfen werden, nachdem new ausgewertet aber bevor das interne shared_ptr -Objekt konstruiert wurde?

bad_alloc wegen Reallokation des Containers.

Columbo

camper schrieb:

bad_alloc wegen Reallokation des Containers.

Weswegen habe ich wohl nicht kritisch geschrieben? Ich denke nicht, das bei einem bad_alloc (es sei denn, man hat irgendetwas eigenes gebastelt) noch viel Aufhebens wegen eines Lecks gemacht wird?

camper

Arcoth schrieb:

camper schrieb:

bad_alloc wegen Reallokation des Containers.

Weswegen habe ich wohl nicht kritisch geschrieben? Ich denke nicht, das bei einem bad_alloc (es sei denn, man hat irgendetwas eigenes gebastelt) noch viel Aufhebens wegen eines Lecks gemacht wird?

Und seit wann unterscheidet Exceptionsicherheit zwischen kritischen und nicht-kritischen Exceptions? Das ist überhaupt eine sinnlose Unterscheidung: Exceptions werden geworfen, weil ein bestimmter Zustand nicht lokal behandelt werden kann, das impliziert, dass eine Unterscheidung zwischen kritisch und nicht-kritisch ebenso lokal nicht getroffen werden kann. Was soll eigentlich argumentiert werden? Dass Exceptionsicherheit nur nach Lust und Laune erfolgen sollte?

Arcoth schrieb:

Weswegen habe ich wohl nicht kritisch geschrieben?

Ja, warum weigentlich? Das lenkt nur ab.

hustbaer

Ich bin hier mit camper einer Meinung.
Sich dauernd zu überlegen "kann hier überhaupt ein Fehler passieren den wir sinnvoll behandeln können" führt bloss zu Kopfschmerzen und ... Fehlern.
In Ausnahmefällen mag das angebracht sein, aber i.A. ist es mMn. wesentlich sinnvoller Dinge per Default "richtig" zu machen. Statt sich immer wieder zu überlegen was man an der jeweiligen Stelle gerade alles falsch machen kann ohne damit ein Problem zu verursachen.

camper schrieb:

Arcoth schrieb:
camper schrieb:
container.emplace_back(new MyClass(*sharedPtr));
Ist böse, da nicht exceptionsicher.
Und welche (nicht kritische) Exception soll geworfen werden, nachdem new ausgewertet aber bevor das interne shared_ptr -Objekt konstruiert wurde?
bad_alloc wegen Reallokation des Containers.

ist hier nicht gerade der witz das emplace_back den neuen platz im container zu ERST allokiert und dann das new darauf anwendet?
Weil das ist doch der konkrete zweck von emplace_back.. man kopiert oder moved nicht unnötig da der container durch variadische template magie den käse direkt mit emplacement new auf das containerelement anwendet.. Also muss es ja vorhanden sein

camper

asdfasdsdasd schrieb:

ist hier nicht gerade der witz das emplace_back den neuen platz im container zu ERST allokiert und dann das new darauf anwendet?

Richtig, nur ist das Containerelement ein shared_ptr und nicht das worauf dieser zeigen soll. Das worauf er zeigen soll existiert bereits beim Aufruf der Funktion und wird nur über einen rohen Zeiger referenziert. Und im Gegensatz zu shared_ptr<T> hat vector<shared_ptr<T>> nat. keine spezielle Regel, die besagt, dass im Fall von geworfenen Exceptions vorher noch delete auf irgendwelche Zeigerargumente angewendet wird.

Columbo

Exceptions werden geworfen, weil ein bestimmter Zustand nicht lokal behandelt werden kann, das impliziert, dass eine Unterscheidung zwischen kritisch und nicht-kritisch ebenso lokal nicht getroffen werden kann.

Tut es das? Einer kritische Exception muss nicht die unmittelbare Terminierung des Programms folgen. Ich kann, auch von außen, auf eine kritische Exception gewissermaßen reagieren. Genauso wie nicht-kritische Exceptions keine lokale Behandlung implizieren.

Was soll eigentlich argumentiert werden? Dass Exceptionsicherheit nur nach Lust und Laune erfolgen sollte?

Wie kommst du darauf, dass irgendetwas argumentiert werden soll? Ich wollte lediglich wissen, warum das konkrete Statement "böse" genannt wurde, wo AFAICS keinerlei praktische Gefahr besteht: Das Programm müsste gewiss vorzeitig beendet werden, da die Reallokation fehlschlug (welche selbst nicht all zu viel Speicher benötigen dürfte).

Das ändert aber nichts, und ich stimme natürlich zu, dass das Statement schlechtem Stil entspringt (und den anderen Punkten sowieso), und man sich schon gar nicht für Gewöhnlich den Kopf darüber zerbricht, ob ein rohes new durchgehen könnte. Ich wollte keine Diskussion über konsequentes Anwenden von exception safety lostreten, das befürworte ich wohl sehr.

Sich dauernd zu überlegen "kann hier überhaupt ein Fehler passieren den wir sinnvoll behandeln können" führt bloss zu Kopfschmerzen und ... Fehlern.

My word. Ich schätze, ich sollte wohl zugeben, dass ich nur clever sein wollte.