Destruktor im Konstruktor ??

Shade Of Mine

Gutes Exception Handling funktioniert quasi komplett ohne try/catch.

Also ein paar try/catch sind notwendig, aber sehr sehr sehr sehr sehr sehr sehr sehr sehr wenige.

Siehe:
http://magazin.c-plusplus.net/artikel/Exception-Handling
http://magazin.c-plusplus.net/artikel/Modernes Exception-Handling Teil 1 - Die Grundlagen
http://magazin.c-plusplus.net/artikel/Modernes Exception-Handling Teil 2 - Hinter den Kulissen

Shade Of Mine schrieb:

Also ein paar try/catch sind notwendig, aber sehr sehr sehr sehr sehr sehr sehr sehr sehr wenige.

Ich finde, das sollte man nicht so pauschalisieren.

SeppJ

happystudent schrieb:

beg_offl schrieb:

Macht man das wirklich so? Ich hab noch nicht soviel mit Try und Catch gemacht, aber wird das dann nicht irgendwann uferlos?

Du meinst uferlos weil du dann überall wo du ein solches Objekt erstellst einen try-catch block schreiben musst?

Also ich mach das immer ungefähr so:
#include <iostream>

int my_main() {
    // Hier die "echte" main in der alles gemacht wird
}

int main() {
    // Hier wird nur "my_main" aufgerufen
    try {
        return my_main();
    }
    catch (std::exception const &ex) {
        std::cerr << ex.what() << '\n';
    }
}
Dann kannst du dir sicher sein dass du eine Fehlermeldung bekommst wenn eine exception geworfen wird und du musst den try-catch block nur einmal schreiben. Natürlich kannst du lokal in my_main (oder von diesem aufgerufenen Unterfunktionen) noch weitere try-catch Blöcke einfügen um diese gegebenenfalls anders zu behandeln.

Auf welcher (hosted) Implementierung arbeitest du denn, die dir keine Rückmeldung über ungefangene Exceptions beim Abbruch gibt? Und selbst wenn du paranoiderweise annimmst, dass deine Umgebung nicht das tut, was du hier von Hand versuchst, wäre es wohl immer noch deutlich übersichtlicher, einen entsprechenden terminate-Handler zu setzen. Und noch einen unexcepted-Handler für die paranoid²-Absicherung.

Also so nicht machen. Verstanden...
SeppJ, nicht falsch verstehen, aber wie würdest du es generell machen, als "Großmeister" ?

SeppJ

beg_off schrieb:

SeppJ, nicht falsch verstehen, aber wie würdest du es generell machen, als "Großmeister" ?

Siehe Shade of Mines Beiträge.

Oh, Sorry übersehen. Das zieh ich mir mal rein.

evtl. noch was zu

raw pointer mit new geht auch

Kann das bitte jmd. zeigen? Also wie man mit new (obwohl man nicht machen soll) das ganze löst?

???

Hast du das etwa auch übersehen?

Hi schrieb:

unique_ptr<tmp> uptr;
try
{
    uptr.reset(new temp(...));
}

Mit nem rohen Zeiger geht es genauso.

Nö, aber falsch verstanden.
Besten Dank an alle!

Ethon

Man schreibt einen try/catch Block wenn man eine Exception sinnvoll behandeln kann. Ansonsten lässt man sie weitersegeln.

Hast du das etwa auch übersehen?

Hi schrieb:
unique_ptr<tmp> uptr;
try
{
    uptr.reset(new temp(...));
}
Mit nem rohen Zeiger geht es genauso.

Gibt es überhaupt eine möglichkeit ein Objekt oder Variable die in einem Try / Catch Block erzeugt wird, außerhalbe dieses Blockes zu benutzen?

Bashar

trycatchnix schrieb:

Gibt es überhaupt eine möglichkeit ein Objekt oder Variable die in einem Try / Catch Block erzeugt wird, außerhalbe dieses Blockes zu benutzen?

Du hast es doch gerade selbst zitiert

Also bleibt ein mit new erzeugtes Objekt oder dergleichen generell außerhalb des Try Blocks gültig?

tkausl

trycatchnix schrieb:

Also bleibt ein mit new erzeugtes Objekt oder dergleichen generell außerhalb des Try Blocks gültig?

Vorrausgesetzt der Konstruktor throwt nicht, ja.

Bashar

Ja, natürlich. Ein mit new erzeugtes Objekt existiert, bis es mit delete gelöscht wird.

Vorrausgesetzt der Konstruktor throwt nicht, ja.

In diesem Fall würde das Objekt ja nicht erzeugt.

Tja, dann ist ja alles klar. Danke!

tkausl

Bashar schrieb:

Ja, natürlich. Ein mit new erzeugtes Objekt existiert, bis es mit delete gelöscht wird.

Vorrausgesetzt der Konstruktor throwt nicht, ja.

In diesem Fall würde das Objekt ja nicht erzeugt.

Nunja, aber, der Speicher wird Reserviert und der Konstruktor wird gestartet. Dazu kommt: Sobald nur ein einziger der deligierten Konstruktoren komplett durchläuft ohne zu throwen, gilt das Objekt als Konstruiert und der Destruktor darf aufgerufen werden (auch bei einem Throw in einem der nachfolgenden Konstruktoren).

camper

tkausl schrieb:

Sobald nur ein einziger der deligierten Konstruktoren komplett durchläuft ohne zu throwen, gilt das Objekt als Konstruiert und der Destruktor darf aufgerufen werden (auch bei einem Throw in einem der nachfolgenden Konstruktoren).

Soll heißen? Wenn ein delegierender Konstruktor wirft, wird das Objekt vom Compiler zerstört und die entsprechende Deallokationsfunktion aufgerufen. Wo ist da Spielraum für "Destruktor darf aufgerufen werden"?

Columbo

Ein mit new erzeugtes Objekt existiert, bis es mit delete gelöscht wird.

auto p = new int;
new (p) int;

Ist gültiger Code, und das ursprüngliche Objekt existiert nicht mehr. (Hängt von der Definition des Worts "existieren" ab; Streng genommen lebt das Objekt nicht mehr.)

tkausl

camper schrieb:

Wo ist da Spielraum für "Destruktor darf aufgerufen werden"?

Sorry falls das unklar war, ich meinte damit nicht, dass der Programmierer dann den Konstruktor aufrufen darf oder kann, sondern dass laut Standard der Destruktor vom Compiler aufgerufen wird, sobald nur einer der deligierten Konstruktoren erfolgreich durchlaufen ist und ein späterer dann throwt.

Bashar

Arcoth schrieb:

Ein mit new erzeugtes Objekt existiert, bis es mit delete gelöscht wird.
auto p = new int;
new (p) int;
Ist gültiger Code, und das ursprüngliche Objekt existiert nicht mehr.

Ich habe so geantwortet, dass es dem Niveau der Frage angemessen ist. Unter Standardannahmen stimmt das auch; bei Placement-new oder bei überladenem new etc. vielleicht nicht mehr, aber wer sowas einsetzen kann, muss nicht fragen, welche Objekte aus einem try-Block außerhalb noch leben.