ich komme aus der Javawelt und muss leider ein paar Klassen nach C++ portieren. Gibt es hier was Vergleichbares wie Interfaces? Wie gut sind Exceptions in C++ umgesetzt?

Gruß Gilli

Das sieht dann z.B. so aus:

class MyInterface
{
public:
   virtual void doThat() = 0;

protected:
   ~MyInterface() { }
};

Eine kleine Korrektur: der Destruktor sollte virtual sein:

class MyInterface
{
public:
   virtual void doThat() = 0;

protected:
   virtual ~MyInterface() { }
};

ich komme aus der Javawelt und muss leider ein paar Klassen nach C++ portieren.

Oha!
Beachte, dass Du ein Java-Design nicht 1:1 nach C++ übertragen kannst. Das Ergebnis ist meist genauso schlecht wie eine Wort-für-Wort-Übersetzung einer Videorekorder-Anleitung von Chinesisch auf Englisch. (Kein Scherz!)

Gilli82 schrieb:

Gibt es hier was Vergleichbares wie Interfaces?

Es gibt abstrakte Klassen.

class abc
{
public:
  virtual ~abc() {} // <-- brauchst Du, um Objekte "polymorph löschen" zu klönnen
  virtual void foo(int) = 0;       // <-- abstrakt
  virtual int bar() const = 0;  // <-- auch abstrakt
};

Gilli82 schrieb:

Wie gut sind Exceptions in C++ umgesetzt?

Du wirst erst mal das Stack-Trace-Feature vermissen. Wenn eine Ausnahme fliegt, die nicht gefangen wird, bricht das Programm sofort ab ohne einen Mucks -- es sei denn, Du hast einen entsprechenden Handler installiert. Desweiteren funktionieren "exception specifications" anders in C++. In Java werden die statisch überprüft, in C++ nicht -- daher sind sie eher nutzlos! Die beste Praxis ist es, keine Funktionen mit exception specifications zu dekorieren. Also:

void dingsbums() throw(std::runtime_error);

ist nix gut, wobei

/**
 * @throw std::runtime_error in case file xyz didn't exist.
 */
void dingsbums();

okay ist. Mach Dich mit der Dokumentation Deines Compilers und Deines Debuggers vertraut. Unter'm Debugger lässt sich vieles leichter nachvollziehen und den Aufruf-Stack gibt's da auch zu sehen. Dein(e) Compiler/Standardbibliothek bietet eventuell einen schönen "STL-Debug-Modus" an, welcher allerlei Zusatzüberprüfungen zwecks Fehlerfrüherkennung macht. Das kann sehr praktisch sein.

Mit hoher Wahrscheinlichkeit wird das, was Du in C++ schreibst erstmal totaler Müll sein. Das war bei mir auch so. Lerne die Sprache richtig. Nachdem Du die Sprache kennengelernt hast, lese das Buch "Effective C++" von Scott Meyers -- wenn möglich in der 3. Auflage.

Nachtrag:
Als Java-Programmierer wirst Du vielleicht erst mal dazu neigen, alles in Klassen mit vielen virtuellen Elementfunktionen zu verpacken. Das ist nicht immer sinnvoll. C++ bietet auch andere Abstraktionsmöglichkeiten.

Nachtrag2:
Mir fällt noch das Konzept der getrennten Übersetzung ein. Das hatte ich auch anfangs nicht sofort verstanden. Lass Dir das und die "one definition rule" von den schlauen Büchern erklären.

Viel Spaß beim Lernen!

kk

Eine kleine Korrektur: der Destruktor sollte virtual sein:

Nö..

Entweder public virtual ODER protected non- virtual...

public virtual ist nur dann nötig wenn das Objekt, polymorph gelöscht werden soll (wie krümelkacker korrekt anmerkte).

Edit:
Das gilt für Klassen die als Interface / Basis Klasse dienen. Nur um den Kontext klarzustellen.

@manni66:

Eine kleine Korrektur: der Destruktor sollte virtual sein:

Nö..

Entweder public virtual ODER protected non- virtual...

public virtual ist nur dann nötig wenn das Objekt, polymorph gelöscht werden soll (wie krümelkacker korrekt anmerkte).

Edit:
Das gilt für Klassen die als Interface / Basis Klasse dienen. Nur um den Kontext klarzustellen.

Aus Kompatibilitätsgründen zu anderen Compilern, der Lesbarkeit und der Reduktion von Fehlerquellen sollte man sich das aber angewöhnen.

Oder sehe ich das falsch?

Aus Kompatibilitätsgründen zu anderen Compilern, der Lesbarkeit und der Reduktion von Fehlerquellen sollte man sich das aber angewöhnen.

Das musst Du mir jetzt aber genau erklären...

Simon

Danke trotzdem für die Hilfe.

Gruß Gilli

Desweiteren funktionieren "exception specifications" anders in C++. In Java werden die statisch überprüft, in C++ nicht -- daher sind sie eher nutzlos! Die beste Praxis ist es, keine Funktionen mit exception specifications zu dekorieren.

Eine Frage: Warum?

Ich arbeite hauptsächlich mit gcc, und dort ist es so, dass eine Exception nur "weitergeworfen" wird, wenn sie auch in der Spezifikation der Methode drinsteht (oder die Methode keine Spezifikation hat), ansonsten wird "terminate()" aufgerufen, und die Meldung ausgegeben welche Exception (mit what()-Ausgabe) zu dem Abbruch führt. Dank diesem Verhalten habe ich schon öfters fehlende "catch"-Blöcke finden können.

Also zurück zur Frage: Warum ist das nutzlos?

Herb Sutters GOTW Reihe:
http://www.gotw.ca/gotw/082.htm

Simon

Edit:
Und wenn ich schon dabei bin noch bezüglich public virtual / protected non-virtual Destruktor: http://www.gotw.ca/publications/mill18.htm

Ich arbeite hauptsächlich mit gcc, und dort ist es so, dass eine Exception nur "weitergeworfen" wird, wenn sie auch in der Spezifikation der Methode drinsteht (oder die Methode keine Spezifikation hat), ansonsten wird "terminate()" aufgerufen, und die Meldung ausgegeben welche Exception (mit what()-Ausgabe) zu dem Abbruch führt. Dank diesem Verhalten habe ich schon öfters fehlende "catch"-Blöcke finden können.

Jetzt, nachdem du die Antwort von theta gelesen hast und vielleicht eine Alternative finden möchtest, wie du die fehlenden Catch-Blöcke finden kannst, sei noch dies gesagt:
1. Es gibt Programme, welche dies für dich prüfen können.
2. Man kann auch in der main ein globales try-catch machen. Wenn man zudem sein Design entsprechend anpasst, kann man trotz auftreten eines Fehlers in der main , die Daten noch retten und sichern.
Ich habe sogar schon gesehen, wie jemand das Programm in der main dann neugestartet hat mit den geretteten Daten. Also quasi: "Fataler Fehler, Daten gerettet, Log Eintrag erstellt, sie dürfen weiterarbeiten!"

Grüssli

Die Alternative wird dann so aussehen:

void f(int);                 // <-- kann Ausnahme werfen
void g(int) noexcept;        // <-- wirft keine Ausnahme
void h(int) noexcept(true);  // <-- wirft keine Ausnahme
void k(int) noexcept(false); // <-- kann Ausnahme werfen

...wobei die Doppelverneinung im letzten Fall etwas gewöhnungsbedürftig ist.

Darüberhinaus wird noexcept ein Compile-Zeit-Operator sein, mit dem man Ausdrücke darauf überprüfen kann, ob sie garantiert keine Ausnahme werfen können:

bool nx_f = noexcept( f(23) ); // false
bool nx_g = noexcept( g(42) ); // false oder true
bool nx_h = noexcept( h(17) ); // false oder true
bool nx_k = noexcept( k(29) ); // false

Mit anderen Worten: Der noexcept-Operator darf pessimistisch sein und immer false zurückgeben. Der Compilerhersteller sollte sich aber hier Mühe geben und die noexcept-Spezifikation beachten. Wenn der Operator true liefert, wirft der Ausdruck garantiert keine Ausnahme.

kk

2. Man kann auch in der main ein globales try-catch machen.

Und genau das führt dazu, dass freeorion auf meinem Rechner mit "main() caught exception(std::exception): unregistered class" nicht aussteigt, sondern endlos in der Event-Schleife weiterläuft. Mit dieser Meldung wird niemand jemals den Fehler finden ohne im geistigen "Single-Step-Modus" durchlatschen zu müssen.

Aber zurück zum Thema, ich kenne Sutter. Ich habe trotzdem mal den Inhalt hinter dem Link oben überflogen, und eine Sache ist Bemerkenswert:

Sutter schrieb:

Here’s what many people think that exception specifications do:

• Guarantee that functions will only throw listed exceptions (possibly none).
• Enable compiler optimizations based on the knowledge that only listed exceptions (possibly none) will be thrown.

Da habt Ihr natürlich Recht, wer von einer dieser beiden (oder von beiden) Annahmen ausgeht, liegt falsch und wird auf Probleme stoßen.
(Siehe Ralf Schneeweiß, Moderne C++-Programmierung, Seite 162ff)
Aber:

Sutter schrieb:

The above expectations are, again, deceptively close to being correct. Consider again the code in Example 1(b):

// Example 1(b) reprise, and two
// potential white lies:
//
int Gunc() throw();    // will throw nothing (?)
int Hunc() throw(A,B); // can only throw A or B (?)

Are the comments correct? Not quite. Gunc() may indeed throw something, and Hunc() may well throw something other than A or B! The compiler just guarantees to beat them senseless if they do… oh, and to beat your program senseless too, most of the time.

Und wenn ich, wie in meinem Post oben beschrieben, genau _dieses_ Verhalten haben möchte? Wenn ich erzwingen möchte das "hunc()" sich auch wirklich um alle Ausnahmen außer A und B selber kümmern _muss_? Dann kann ich mit der obigen Spezifikation dafür sorgen, dass entweder der Compiler und/oder das am ende stehende Programm mir sinnvoll (nicht sinnvoll siehe oben mit dem all-in-one-catch) um die Ohren fliegt.

Also zurück zur Frage: Warum ist das nutzlos?

Es erscheint mir eher, dass es wie bei vielen Details in C++ ist, es kommt auf das Wissen an, was geschieht.

Spätestens wenn man an einem Toolkit oder Framework arbeitet ist das schon wichtig, dass die Nutzer sich auf die per Ausnahmespezifikation getätigten Aussagen verlassen können. Auch ein Kommentar hilft da nicht weiter. Aber ein brutales terminate() im Testprogramm wird den Autoren des Übeltäters wohl eher zum Überarbeiten anregen, als eine nichtssagende, wer-weiß-woher stammende ::std::exception in einem Fehlerbericht.

Abhängigkeiten und externe Programme würde ein ToolKit-/FrameWork-/Bibliotheks-Programmierer ja sicher vermeiden wollen, gell?

@Krümelkacker:
Der kommende C++-Standard fühlt sich fast schon wie Perl6 oder Duke Nukem forever an. Diskutiert/gearbeitet wird daran seit gefühlten Äonen, aber zumindest im gcc-4.4.4, den ich nutze gilt nach wie vor:

#ifndef __GXX_EXPERIMENTAL_CXX0X__
# include <c++0x_warning.h>

(Aber ich freue mich darauf wenn das ein Ende hat...)

Gerade im Hinblick auf das Exception-Handling, und der Verschiebung in die Kompilierzeit blicke ich dem sehr positiv entgegen. Denn eine solche Überprüfung ist natürlich um ein Vielfaches sinnvoller und gewinnbringender als ein terminate()-Abbruch eines laufenden Programms.

P.S.: Ich frage mich gerade, ob es sinnvoll ist das ToolKit, an dem ich gerade arbeite, schon heute nach C++0x zu "portieren" ("aufbohren" triffts wohl eher)... Was meint Ihr? Immerhin müsste dann jeder Nutzer mit "-std=c++0x" kompilieren.

Edith hat anzumerken: Erst im März 2011 soll C++0x Draft abgeschlossen sein, und WG21 (http://www.open-std.org/jtc1/sc22/wg21/) geht laut wikipedia davon aus, dass es bis zum ISO Standard nochmal sechs bis 12 Monate dauert. Ich glaube C++0x ist (noch) keine Option.

Dravere schrieb:

2. Man kann auch in der main ein globales try-catch machen.

Und genau das führt dazu, dass freeorion auf meinem Rechner mit "main() caught exception(std::exception): unregistered class" nicht aussteigt, sondern endlos in der Event-Schleife weiterläuft. Mit dieser Meldung wird niemand jemals den Fehler finden ohne im geistigen "Single-Step-Modus" durchlatschen zu müssen.

Tja, auch beim Werfen von Exceptions gilt es sinnvolle Informationen mitzuliefern. Oh Wunder, man könnte sogar Zeilennummer und File-Namen mitwerfen. Siehe die Makros __FILE__ und __LINE__ .

Yamakuzure schrieb:

Und wenn ich, wie in meinem Post oben beschrieben, genau _dieses_ Verhalten haben möchte? Wenn ich erzwingen möchte das "hunc()" sich auch wirklich um alle Ausnahmen außer A und B selber kümmern _muss_? Dann kann ich mit der obigen Spezifikation dafür sorgen, dass entweder der Compiler und/oder das am ende stehende Programm mir sinnvoll (nicht sinnvoll siehe oben mit dem all-in-one-catch) um die Ohren fliegt.

Du willst ein Verhalten, welches nicht mal garantiert ist? Siehe den letzten Teil:

The compiler just guarantees to beat them senseless if they do… oh, and to beat your program senseless too, most of the time.

Zum Beispiel ignoriert der MSVC die Dinger rigoros
Zudem ist auch keine Garantie vorhanden, welche Informationen du von einem terminate erhälst. Das kann grundsätzlich auch einfach so lauten: "The program terminated." Eine Menge an Informationen, muss ich schon sagen

Yamakuzure schrieb:

Der kommende C++-Standard fühlt sich fast schon wie Perl6 oder Duke Nukem forever an. Diskutiert/gearbeitet wird daran seit gefühlten Äonen, ...

Leicht übertrieben. Der letzte Standard war von 2003. Im 2006 kam der TR1 heraus. Und wie es aktuell aussieht, wird Ende 2011 der neue C++ Standard von der ISO veröffentlicht werden.

Grüssli

Yamakuzure schrieb:

Dravere schrieb:

2. Man kann auch in der main ein globales try-catch machen.

Und genau das führt dazu, dass freeorion auf meinem Rechner mit "main() caught exception(std::exception): unregistered class" nicht aussteigt, sondern endlos in der Event-Schleife weiterläuft. Mit dieser Meldung wird niemand jemals den Fehler finden ohne im geistigen "Single-Step-Modus" durchlatschen zu müssen.

Tja, auch beim Werfen von Exceptions gilt es sinnvolle Informationen mitzuliefern. Oh Wunder, man könnte sogar Zeilennummer und File-Namen mitwerfen. Siehe die Makros __FILE__ und __LINE__ .

Okay, Missverständnis: Ich habe mit der Entwicklung von freeorion nichts zu tun. Und meine Exceptions halten sich an das Muster, dass in der PDFLib verwendet wird, also nicht nur "was", sondern auch "woher". Wäre der Kram auf meinem Mist gewachsen, würde die Ausgabe ungefähr so lauten:
"main() caught exception(pwx::mrf::ExceptionBase): [TMemRing->isValueIn()] Data not found" ... Genau das hatte ich gestern Abend, und die Methode isValueIn() hat nur fünf Zeilen, von denen nur eine werfen kann, und die war auch Schuld.

Dravere schrieb:

Du willst ein Verhalten, welches nicht mal garantiert ist?

Nein, ich möchte mich selbst zwingen nur das auszuliefern, was tut wie geheißen. Wenn ich eine Methode mit "throw()" angebe, dann darf diese auch wirklich nichts werfen. Mache ich bei der Umsetzung etwas falsch, soll es knallen, und nicht Unsinn über ein main-catch ausgegeben werden. (Und da ich mit gcc schreibe und teste kann mir das verhalten des MSVC egal sein. Zum Glück. ;))

Draveres schrieb:

Zudem ist auch keine Garantie vorhanden, welche Informationen du von einem terminate erhälst. Das kann grundsätzlich auch einfach so lauten: "The program terminated." Eine Menge an Informationen, muss ich schon sagen

Auf meinem System, das für die Entwicklung zählt, ist es zum Glück anders, sonst würde ich es nicht so machen.

Draveres schrieb:

Leicht übertrieben. Der letzte Standard war von 2003. Im 2006 kam der TR1 heraus. Und wie es aktuell aussieht, wird Ende 2011 der neue C++ Standard von der ISO veröffentlicht werden.

Oder Anfang 2012, wie ich schrieb, fals du meinen Edit noch gesehen hast. Ich habe hier auch nicht nur absichtlich, sondern sehr rigoros übertrieben, und nicht nur leicht.

Wie dem auch sei, das Gefrickel mit den Ausnahmespezifizierern tue ich mir auch wirklich nur aus den oben genannten Gründen an. Es gibt nämlich noch einen Nachteil: Die Funktionsliste von Code::Blocks findet keine Funktion, die einen Ausnahmespezifikation hat. Sehr nervig!

Und es ist sehr schön, wenn es auf deinem System so läuft. Je nach Verwendung und Grösse deines Projektes, wird es aber nicht bei deinem System bleiben. Ein Code kann auch mal auf einen anderen Kompiler portiert werden. Wenn du OpenSource entwickelst, dann sowieso.

Es gibt so viele Nachteile bei der Ausnahmespezifikation (du listest sogar zusätzlich auf!) und gäbe so viele bessere Methoden, das gleiche zu erreichen, was du über die Ausnahmespezifikation erreichst, ohne all diese Nachteile ... wieso machst du es dann immernoch über die Ausnahmespezifikation?

Grüssli

Also ich versuche das mal anhand eines Falles, den ich vorgestern hatte, wo die Spezifikation mit terminate() ein Glücksfall war:
Eine Methode setzt einen internen Zeiger auf ein Element einer doppelt verketten Liste, und tut dieses je nach Index, der übergeben wird. Die übergebene Zahl wird vorher normalisiert, so dass sie auf jeden Fall "0 <= index < size()" ist.
Die benannte Methode schlägt niemals fehl, es sei denn, es gibt keine Elemente. In diesem Fall wirft sie eine spezielle Ausnahme, die nur von dieser einen Methode geworfen werden kann.
Ich habe eine andere Methode mit throw() markiert. Diese sollte überprüfen, ob es in der Liste ein per Argument übergebenes Element gibt. (Ein kleiner Vorgriff: Ich hatte in genau dieser Methode vergessen den Fall, dass die Liste leer ist, abzufangen. Da dieser Fall aber abgefangen hätte werden müssen, hatte ich auf einen try-catch-Block verzichtet.) Diese Methode geht nun die Liste durch, und muss dafür jedes Element bis zum Ende, oder bis zu einem Treffer überprüfen. Hierfür wird die oben beschriebene Methode in einer Schleife verwendet.

Mit der Technik des globalen try-catch-Blocks (den ich übrigens auch verwende) hätte ich nur die Aussage erhalten, das eine Ausnahme vom Typ der abgefangen Klasse (Im Zweifelsfall std::exception) aufgetreten ist. Der Nutzen wäre gleich null gewesen. Diese Ausnahme kommt immer aus der gleichen Methode, keine sonstwie übergebenen Informationen hätte irgendeine Hilfe sein können.

Mit der terminate()-Methode hatte ich dagegen genau zwei Aussagen:

1.: Es handelt sich um genau diese spezielle Ausnahme, von wo die geworfen wird, war mir als Entwickler natürlich aufgrund ihrer Natur klar.
2.: Die Ausnahme trat an einer Stelle auf, wo sie nicht auftreten durfte.

Nun handelt es sich bei dem Programm um ein Testprogramm für eben dieses zu entwickelnde Toolkit. Und wie das bei Testprogrammen so üblich ist (sein sollte), hat es natürlich vor dem Abbruch genau angemerkt, was geschehen soll.
So war es für mich ein Leichtes den Fehler zu finden, denn der einzige "Übeltäter" konnte die mit throw() markierte Methode sein, die es natürlich auch war.
Am Ende wird es nicht mehr zu einem terminate() kommen können. Zum Einen weil das Testprogramm mir ermöglichen soll alle "Störstellen" zu finden, zum Anderen weil die Ausnahmespezifikationen am Ende wieder entfernt werden.

--- cut ---
Es handelt sich hierbei, _natürlich_, um einen Sonderfall. Ich versuche auch nicht irgendwem weißzumachen, das Ausnahmespezifikation was ganz Tolles wären. Sind sie nicht. Bei einer normalen Applikation würde ich sie eher vermeiden wollen, da sie die Flexibilität einschränken.
Es geht mir nur darum, dass es gerade bei einer so vielfältigen Sprache wie C++ eher ungünstig ist, solche Pauschalaussagen wie "Ist nutzlos" zu tätigen. Vor allem wenn ich den Gegenbeweis "Bunt auf weiß" in meiner IDE vor Augen habe.
Zusätzlich habe ich mit dem FreeOrion-Beispiel auch noch den Gegenbeweis zu "du brauchst nur catch in main()", diesmal "weiß auf schwarz".

Mit der Technik des globalen try-catch-Blocks (den ich übrigens auch verwende) hätte ich nur die Aussage erhalten, das eine Ausnahme vom Typ der abgefangen Klasse (Im Zweifelsfall std::exception) aufgetreten ist. Der Nutzen wäre gleich null gewesen. Diese Ausnahme kommt immer aus der gleichen Methode, keine sonstwie übergebenen Informationen hätte irgendeine Hilfe sein können.

1. Wenn du nützliche Informationen in der Exception verpacken würdest, hätte es durchaus einen Mehrwert gehabt. Man muss ja nicht nur ein catch(...) durchführen in der main. Man kann ja auch die zahllosen verschiedenen Basis-Exception abfangen, welche man verwendet oder sogar ganz anderes zeug. Wenn also sinnvolle Informationen in der Exception vorhanden wären, hättest du auch die nötigen Informationen in der main gehabt.
2. Ein Debugger hätte dir diese Informationen sofort geliefert und gerade dazu sind Debugger auch da.

Yamakuzure schrieb:

Es geht mir nur darum, dass es gerade bei einer so vielfältigen Sprache wie C++ eher ungünstig ist, solche Pauschalaussagen wie "Ist nutzlos" zu tätigen. Vor allem wenn ich den Gegenbeweis "Bunt auf weiß" in meiner IDE vor Augen habe.

Ausnahmespezifikationen sind in der aktuellen Form ziemlich nutzlos. Nicht ohne Grund nimmt man sie aus dem Standard raus. Ich kann mich nur wiederholen, es gibt deutlich besser Alternativen, für das was du erreichen möchtest.

Yamakuzure schrieb:

Zusätzlich habe ich mit dem FreeOrion-Beispiel auch noch den Gegenbeweis zu "du brauchst nur catch in main()", diesmal "weiß auf schwarz".

Das ist doch kein Gegenbeweis. Das ist nur ein Beweis, dass ihre Fehlermeldungen schlecht sind und allenfalls die mitgelieferten Fehlerinformationen.

Grüssli

Und in main() steht:

try
  {
    /* alle möglichen tests */
  }
catch (pwx::mrf::ExceptionBase &e) { /* info handling */ }
catch (std::exception &e) { /* sonstige exception infos */ }
catch (...) { /* Panik! */ }

(*) Gespeichert wird: Objektname, Methodenname, Datei, Zeile, Beschreibung, relevante Daten. Aber das reicht nun einmal nicht immer.

Zu 2.: Ja, ich weiß. Ich verwende gdb sehr intensiv, da er sehr gut in Code::Blocks integriert ist.

Zum "Gegenbeweis": Es ist der Beweis dafür, dass die Pauschalaussage, das try-catch in main() alle Probleme pauschal löst, falsch ist. Man muss schon ein wenig mehr tun, wie du selber ja sagst, gell?

Herb Sutter im C++ Users Journal zu Exception Specifications:
http://www.gotw.ca/publications/mill22.htm

Auch wenn ich Herb Sutters Ausführungen zu C++ als sehr hochwertig betrachte, ist dies in Bezug auf Exceptions definitiv nicht der Fall. Es gibt in C++ keinerlei logischen Grund einen Destruktor nicht als throw() zu definieren, da Exception werfende Destruktoren unweigerlich zu Problemen führen, und früher oder später eine zweite Exception geworfen wird -> terminate(). Da aber in Falle eines werfenden Destruktors das ganze nicht mehr deterministisch passiert, ist der Fehler faktisch schwer zu finden. Daher sollten Destruktoren immer throw() definiert sein.

Es kann doch nicht sein, daß man eine Programmsprache nach den mangelhaften Compiler entwirft. Wenn der Compiler kaputt ist, sollte man ihn reparieren und nicht die Sprache an den kaputten Compiler anpassen.

Du liest den Text nicht.

Doch, tue ich. Ich möchte dich also bitten, wenn ich mir schon die Zeit nehme, deine Beiträge durchzulesen, dass du mir nicht unterstellst, dass ich dies nicht tue. Ich habe einfach deinen Text missverstanden. Wahrscheinlich weil er etwas komplex ist, um einen simplen Sachverhalt zu erklären.

Man hätte nämlich sagen können, dass bei einem globalen try-catch in der main , der Callstack fehlt. Das ist grundsätzlich schon alles, was du kritisierst. Aber wie gesagt, dazu gäbe es ja den Debugger.

Aber den benutzt du ja anscheinend auch:

Yamakuzure schrieb:

Zu 2.: Ja, ich weiß. Ich verwende gdb sehr intensiv, da er sehr gut in Code::Blocks integriert ist.

Dann frage ich mich immer noch, wieso du die throw -Spezifikation verwendest. Mit dem Debugger hättest du diese Informationen schliesslich auch problemlos erhalten.

Yamakuzure schrieb:

Zum "Gegenbeweis": Es ist der Beweis dafür, dass die Pauschalaussage, das try-catch in main() alle Probleme pauschal löst, falsch ist. Man muss schon ein wenig mehr tun, wie du selber ja sagst, gell?

Ich habe dies so nicht gesagt. Nicht mal annähernd. Ich wollte eine Alternative Vorschlagen, welche in vielen Fällen sehr praktisch sein kann. Als eine pauschale Lösung für alle Probleme, habe ich dies nie beworben.

Grüssli

Auch wenn ich Herb Sutters Ausführungen zu C++ als sehr hochwertig betrachte, ist dies in Bezug auf Exceptions definitiv nicht der Fall. Es gibt in C++ keinerlei logischen einen Destruktor nicht als throw() zu definieren, da Exception werfende Destruktoren unweigerlich zu Problemen führen, und früher oder später eine zweite Exception geworfen wird -> terminate(). Da aber in Falle eines werfenden Destruktors das ganze nicht mehr deterministisch passiert, ist der Fehler faktisch schwer zu finden. Daher sollten Destruktoren immer throw() definiert sein.

1. Du solltest lesen, was Herb Sutter da geschrieben hat. Ich zitiere es gerne mal:

Moral #2: Except possibly an empty one, but if I were you I’d avoid even that.

Boost’s experience is that a throws-nothing specification on a non-inline function is the only place where an exception specification “may have some benefit with some compilers” [emphasis mine]. That’s a rather underwhelming statement in its own right, but a useful consideration if you have to write portable code that will be used on more than one compiler platform.

It’s actually even a bit worse than that in practice, because it turns out that popular implementations vary in how they actually handle exception specifications. At least one popular C++ compiler (Microsoft’s, up to version 7.x) parses exception specifications but does not actually enforce them, reducing the exception specifications to glorified comments. But, on the other hand, there are legal optimizations a compiler can perform outside a function, and which the Microsoft 7.x compiler does perform, that rely on the ES enforcement being done inside each function -- the idea is that if the function did try to throw something it shouldn’t the internal handler would stop the program and control would never return to the caller, so since control did return to the caller the calling code can assume nothing was thrown and do things like eliminate external try/catch blocks. So on that compiler, because the checking is not done but the legal optimization that relies on it is done, the meaning of “throw()” changes from the standard “check me on this, stop me if I inadvertently throw” to a “trust me on this, assume I’ll never throw and optimize away.” So beware: If you do choose to use even an empty throw-specification, read your compiler’s documentation and check to see what it will really do with it. You might just be surprised. Be aware, drive with care.

Er schliesst gerade throw() nicht vollständig aus. Mahnt aber zur Vorsicht.

2. Ein Destruktor von einem Stackobjekt oder einem Objekt mit statischer Lebensdauer, welcher eine Exception wirft, löst automatisch ein terminate aus.

3. Ich würde aber anstatt throw() zu nehmen, doch lieber folgendes machen, falls die Unsicherheit wirklich besteht.

try
{
  // ...
}
catch(...)
{
  std::terminate();
}

Ich konnte sowas aber bisher By-Design ausschliessen.

Grüssli

Yamakuzure schrieb:

Du liest den Text nicht.

Doch, tue ich. Ich möchte dich also bitten, wenn ich mir schon die Zeit nehme, deine Beiträge durchzulesen, dass du mir nicht unterstellst, dass ich dies nicht tue. Ich habe einfach deinen Text missverstanden. Wahrscheinlich weil er etwas komplex ist, um einen simplen Sachverhalt zu erklären.

Entschuldige bitte. Ich bin frustriert, weil ich mich irgendwie nicht verständlich machen kann. Außerdem bekomme ich langsam Kopfschmerzen. (Was aber an der Arbeit liegt, nicht am Forum)

Dravere schrieb:

Dann frage ich mich immer noch, wieso du die throw -Spezifikation verwendest. Mit dem Debugger hättest du diese Informationen schliesslich auch problemlos erhalten.

Ich benutze den Debugger bei Bedarf, und in diesem Fall habe ich ihn nicht gebraucht, da in diesem sehr speziellen Fall die terminate() -Ausgabe bereits sofort gezeigt hat, was schief war. Die Spezifikationen werden ab einem bestimmten Stand des Projekts auch wieder entfernt, und normalerweise benutze ich sie garnicht.

Ich habe übrigens nie behauptet, dass du main->try->catch als ultimative lösung beworben hättest, ich habe nur gesagt, dass es keine allgemeingültige Lösung ist, und das du mir darin bereits zugestimmt hast.

@~john:
Ja. Der Destruktor darf niemals eine Ausnahme werfen, schließlich könnte der Destruktor gerade in Folge einer Ausnahme im Rahmen des Stackunwindings aufgerufen werden. Würde er nun eine Ausnahme werfen, gäbe es keine Möglichkeit mehr darauf zu reagieren. Tatsächlich würde sofort terminate() aufgerufen.

Ich benutze den Debugger bei Bedarf, und in diesem Fall habe ich ihn nicht gebraucht, da in diesem sehr speziellen Fall die terminate() -Ausgabe bereits sofort gezeigt hat, was schief war. Die Spezifikationen werden ab einem bestimmten Stand des Projekts auch wieder entfernt, und normalerweise benutze ich sie garnicht.

Du entfernst die Spezifikation später sogar? Das ist doch ein riesiger Aufwand. Wieso startest du das Programm nicht immer mit dem Debugger? Während mein Programm in der Entwicklungsphase ist, starte ich es immer mit einem Debugger. Es ist eher die Ausnahme, wenn ich es ohne Debugger starte.

Yamakuzure schrieb:

Ich habe übrigens nie behauptet, dass du main->try->catch als ultimative lösung beworben hättest, ich habe nur gesagt, dass es keine allgemeingültige Lösung ist, und das du mir darin bereits zugestimmt hast.

Also moment:
1. Du hast gesagt, dass ein globales try-catch bei der main zum Verhalten von FreeOrion führt. Ich habe bereits gesagt, dass dies nicht das Problem des globalen try-catch ist, sondern dass die Entwickler hinter FreeOrion womöglich Fehler in ihrem Exception Design haben.
2. Später hast du meine Aussage zu einem "du brauchst nur catch in main" irgendwie umformuliert. Das habe ich aber so nie gesagt, nicht in diesem Kontext und wurde auch in diesem Thread nie so erwähnt. Da nur ich allerdings etwas von catch in der main gesagt habe, habe ich dies darauf zurückgeführt, dass du meinst, ich hätte dies so gemeint.
3. Du hast dann gesagt: "Es ist der Beweis dafür, dass die Pauschalaussage, das try-catch in main() alle Probleme pauschal löst, falsch ist.". Welche Pauschalaussage nun, wenn du behauptest, dass du nie behauptet hättest, dass ich main-try-catch als Pauschallösung für alle Probleme beworben hätte.

... uh, der letzte Satz gibt einem wirklich Kopfweh

Grüssli

1. Du solltest lesen, was Herb Sutter da geschrieben hat. Ich zitiere es gerne mal:

Stell Dir mal vor, das habe ich nicht zum erstenmal gelesen, und jedesmal aufs neue stelle ich fest, daß das ein ziemlicher Kappes ist. Denn es werden in erster Linie Argumente wegen kaputter Compiler oder suboptimaler Implementierung angeführt, und das kann beim besten Willen kein Argument sein die Sprache abzuändern.

Denn man kann sehr wohl einen Compiler schreiben, der erkennt, daß in einer Funktion keinerlei Code von Nöten ist, wenn in ihm ausschließlich throw() Funktionen benutzt werden. Insofern wäre dies ein Aufruf gewesen, die Compiler zu verbessern. Man will in Bezug auf throw() dieses Verhalten nun über ein anderes Sprachkonstrukt erreichen. Aber das ist schlecht. Es verkompliziert die Sprache weiter und macht alten Code kaputt (früher oder später), ohne dafür irgend einen triftigen Grund (bezüglich des Sprachdesigns) zu liefern. Schlußendlich macht man das nur, weil Compilerhersteller nicht willens sind ihre Compiler zu verbessern.

Dravere schrieb:

3. Ich würde aber anstatt throw() zu nehmen, doch lieber folgendes machen, falls die Unsicherheit wirklich besteht.

Damit wird eben gerade nicht dokumentiert, daß diese Klasse bei Destruktion keine Exception wirft. Die Eigenschaft "wirft nicht bei Destruktion" ist fundamental und Eigenschaft des Interfaces. Wenn es eine Verletzung des Interfaces gibt, dann hat es keinen Sinn das Programm weiterlaufen zu lassen, da schon längst der Zustand "undefined behavior" erreicht ist.