Destruktor im Konstruktor ??

cpp_beginner

Guten Morgen,

hatte jetzt viel über Klassen gelesen in meinem Lehrbuch (Primer), und wollte mich jetzt mal an eine eigene gaaaanz ganz simple Klasse machen... .
Also funktionieren tut alles soweit( Kein wunder bei dieser wahnsinns anwendung).

Jedoch ist meine Frage wie man das mit dem Konstruktor generell "richtig" macht.
Sprich : Wenn im Konstruktor was schief läuft will ich kein Objekt bzw. kein ungültiges Objekt hinterlassen. Wenn ich da jetzt den Destruktor aufrufe... ok, das sieht erst mal gut aus... Aber beim Verlassen des Gültigkeitsbereich´s hier hald main, wird der Destruktor nochmals aufgerufen. Kann das dann nicht in die Hose gehen?

Hier mal der Code, das durchgemische von mal this-> und mal nicht bitte ich zu übersehen, war viel "Probier mal alles gelesene aus".

temp.hpp:

class temp{

public: 

	 temp(std::string input);
	 ~temp();

	 void cel();
	 void fah();

private:

	 float value_;
	 float cel_;
	 float fah_;
	 const float to_cel_ =  0.556;
	 const float to_fah_ =  1.8;
	 const float fahr_ = 32.0;

	 void init(std::string &buff);	

} ;

temp.cpp:

temp::temp(std::string input){

	 init(input);
}

temp::~temp(){

//	std::cout << "Temperature Object destroyed\n";
}

void temp::init(std::string &buff){

	this->fah_ = 0.0;
	this->cel_ = 0.0;

	std::stringstream buffer(buff);
	buffer >> this->value_ ;

	if (buffer.fail()){
		std::cout << "Your Input String is not Valid\n";
		this->~temp();                            // Hier habe ich starke Zweifel!!?!?
		exit(911);
	}/*else{
		std::cout << "\nInit Done. Object Created\n";
	} */

} 

void temp::cel(){

	this->cel_ = (value_ - fahr_) * to_cel_;
	std::cout << "\n" <<  value_ << " ==>> " << this->cel_ << static_cast<char>(248) << " Celsius\n";	

}

void temp::fah(){

	this->fah_ = (value_ * to_fah_) + fahr_; 
	std::cout << "\n" << value_ << " ==>> " << std::fixed << std::setprecision(1) <<  this->fah_ << static_cast<char>(248) << " Fahrenheit\n";

 }

Meine Frage ist nun, wie macht man das richtig? Solte das eher in die Richtung Try Catch gehen, oder oder oder... ?

Faustregeln:
Man ruft den Destruktor nicht auf.
Man schreibt keinen Destruktor, wenn es nichts zu tun gibt.
Im Fehlerfall wirft man eine Exception.

Also erstmal könntest du das hier:

this->fah_ = 0.0;
this->cel_ = 0.0;

in den Konstruktor packen, denn exact dafür ist er da, dein Objekt initialisieren. Wofür braucht man da denn noch eine init() Funktion. Ist doch doppel-gemoppelt, oder nicht? Außerdem könntest du `value_` bzw dein Objekt doch gleich eine Zahl als Parameter übergeben. Also temp(float input);

Aber mal so allgemein, ich denke das ist schon in Ordnung eine Exception im Konstruktor zu thrown, wenn etwas ziemlich schief geht. Davon, dass man im Konstruktor einen Destruktor aufruft habe ich noch nicht gehört, aber da musst du auf die Anderen warten, die wissen da noch ein bissle mehr.

Auf jeden Fall ist doch das hier:

temp::temp(float input) :
value_ {input},
fah_ {0},
cel_ {0}
{
}

Leichter als

temp::temp(std::string input){

     init(input);
}

void temp::init(std::string &buff){

    this->fah_ = 0.0;
    this->cel_ = 0.0;

    std::stringstream buffer(buff);
    buffer >> this->value_ ;

    if (buffer.fail()){
        std::cout << "Your Input String is not Valid\n";
        this->~temp();                            // Hier habe ich starke Zweifel!!?!?
        exit(911);
    }/*else{
        std::cout << "\nInit Done. Object Created\n";
    } */

}

Belli

cpp_beginner schrieb:

Sprich : Wenn im Konstruktor was schief läuft will ich kein Objekt bzw. kein ungültiges Objekt hinterlassen.

Wenn es tatsächlich mal nicht möglich sein sollte, dass der Konstruktor ein gültiges Objekt erstellt (was aber eigentlich die Ausnahme sein sollte), dann sollte eine Exception geworfen werden. Die räumt erst mal alles im Konstruktor evtl. lokal angelegte weg und hinterlässt dann auch keine Reste.
Es gibt wohl ein paar ganz exotische Fälle, wo man selbst explizit einen Destruktor aufruft (aber nicht im Konstruktor!), aber im Normalfall sollte man das unterlassen.

Ok, danke erstmal.

Wie würde das mit der Exception im Konstruktor dann aussehn? Also der Try Catch Block im Konstruktor oder ausserhalb der Klasse ? (Try Klasse erstellen, die Klasse wirft... Oder im Konstruktor irgendwas prüfen und dann nur throw..?)

Belli

Der Konstruktor wirft die Exception:

class A
{
   public:
      A(){/*Falls ich kein vernünftiges Objekt erstellen kann:*/
            throw "Fehler";}
};

Dann muss aber in der Main , das "Anlegen" des Objekts im Try Block stehen... Somit ist aber auch der Folgecode, der mit dem Objekt arbeitet nur im Try Block gültig, ausser ich wurschtel mit nem Zeiger rum...

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

Ist der Zugriff über den Pointer überhaupt "gültig"? Das Objekt wurde ja eigentlich beim Verlassen des Try Blocks vom Destruktor zerstört...

int main() {

temp *pt1 = nullptr;

try {

	temp T1("12");
	pt1 = &T1;
}catch(const char *Error){
	std::cerr << Error;
}

if (pt1 != nullptr){

	pt1->cel();
	pt1->fah();
}

Konstruktor ungefähr so :

temp::temp(std::string input){

	this->fah_ = 0.0;
	this->cel_ = 0.0;

	std::stringstream buffer(input);
	buffer >> this->value_ ;

	if (buffer.fail()){
	    throw "Error in passed String";
	}
}

Uferlos? Irgendwann vielleicht

Genau, T1 ist außerhalb des try{} schon tot! pt1 zeigt dann... genau!
Also besser so:

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

Bashar

beg_offl schrieb:

Dann muss aber in der Main , das "Anlegen" des Objekts im Try Block stehen...

Ja, und? Exceptions sind halt da. Schon sobald du irgendwelche dynamischen Datenstrukturen wie string oder vector benutzt, steht die Möglichkeit eines bad_alloc im Raum.

Bezogen auf das andere Posting, der try-Block muss natürlich nicht nur das Erzeugen des Objektes umfassen. Andernfalls müsstest du das Objekt mit new erzeugen.

Belli

1. Wie gesagt, ist es eher die Ausnahme, dass ein Objekt nicht erstellt werden kann.
2. Wenn aber doch mal, zB ein Datenbankobjekt nicht erstellt werden kann, dann kann man in aller Regel nicht weiterarbeiten, sondern beendet das Programm kontrolliert, oder gibt eine Fehlermeldung aus, oder ...
3. Der Folgecode muss ja nicht in der main stehen:

int main()
{
   try
   {
      DBObjekt db;
      arbeiteMit(db);
   }
   catch(...)
   {
      cout << "DB nicht verfügbar";
   }
}

happystudent

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.

tntnet

beg_offl schrieb:

Ist der Zugriff über den Pointer überhaupt "gültig"? Das Objekt wurde ja eigentlich beim Verlassen des Try Blocks vom Destruktor zerstört...
int main() {
	
temp *pt1 = nullptr;
	
try {
	
	temp T1("12");
	pt1 = &T1;
}catch(const char *Error){
	std::cerr << Error;
}

if (pt1 != nullptr){
	
	pt1->cel();
	pt1->fah();
}

Sicher ist das falsch. Zeiger auf lokale Objekte sind immer gefährlich. Um nicht zu sagen: Zeiger sind eigentlich immer gefährlich und werden leider viel zu oft verwendet.

Hier ist ein Beispiel, was man mit Zeigern eben genau nicht machen soll. Und wie man mit try-catch nicht um gehen sollte. Ich habe in der Regel ein try-catch in meiner main und sonst im Code eher selten. In Deinem Beispiel sagst Du ja: fange den Fehler, gebe ihn aus und dann machst Du weiter. Warum willst Du weiter machen, wenn es doch nicht geklappt hat. Und diese Abfrage auf nullptr kannst Du ganz einfach weg lassen, indem Du die Verarbeitung in das try integrierst:

int main() {

try {
	temp T1("12");
	pt1->cel();
	pt1->fah();
}catch(const char *Error){
	std::cerr << Error;
}

Fragt sich natürlich, warum Du den Zeiger überhaupt benötigst.

Ausserdem sollte man keinen const char* als exception werfen. Mach lieber ein throw std::runtime_error und ein catch (const std::exception& e)... . Dann sind wir schon relativ nah am Code von Belli (den ich so auch nicht schreiben würde, da hier die Annahme vor liegt, dass wenn irgendeine exception fliegt automatisch die "DB nicht verfügbar" ist. Hier meine Variante:

int main()
{
  try
  {
	temp T1("12");
	T1.cel();
	T1.fah();
  }
  catch(const std::exception& e)
  {
	std::cerr << e.what() << std::endl;
  }
}

Einfach, übersichtlich und robust halt. Ich sollte noch erwähnen, dass ich C++ liebe .

Aha. Also danke erstmal für die anschaulichen Beispiele, ich hab das soweit verstanden und werde das in Zukunft so oder so ähnlich umsetzen.

Fragt sich natürlich, warum Du den Zeiger überhaupt benötigst.

von cpp_tutor.de oder so :

Soll ein Objekt innerhalb eines try-Blocks erstellt und danach auch außerhalb des Blocks zur Verfügung stehen, so muss ein entsprechender Objektzeiger, der natürlich außerhalb des try-Blocks definiert wird, eingesetzt werden. Vergessen Sie dabei aber nicht, dass im Fehlerfall das Objekt eventuell nicht gültig ist

[quote]

=>Wollte das in die Richtung umsetzten, hab aber dabei schon gemerkt das es käse ist, da auch wenn kein Fehler vorliegt, der Destruktor beim Verlassen des Try Blocks durchläuft.

Würde es etwas ändern irgendwie mit new zu arbeiten, oder ist hier wirklich uniuque_ptr die Lösung ? (also für "Im Block erstellen", aúßerhalb damit arbeiten... oder geht es hald einfach gar nicht...)

patrick246

unique_ptr ist hier die beste Lösung, raw pointer mit new geht auch, ist allerdings nie so gut wie ein smart pointer. Die Gründe kann man in jedem C++-Forenbeitrag nachlesen, in dem jemand new ohne smart pointer nutzt.

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?

Ich habe in der Regel ein try-catch in meiner main und sonst im Code eher selten.

Quasi so :??:

int main(){

try{
   mein_code() // also so ähnlich wie bei happystudent, in mein_code wird =>ALLES<= verwaltet??
}catch(//wie auch immer...){
  //sth. else...
}

}

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" ?