welche vorteile bietet c++ gegenüber c

volkard

GPC schrieb:

Im Endeffekt heißt das einfach, dass dann halt business as usual gemacht wird, wenn der Destruktor Ressourcen nicht korrekt freigeben konnte?
Bzw. sich das Problem dahingehend ausdehnt, dass man in Destruktoren keine Funktionen aufrufen sollte, die eine Exception werfen könnte.

Ja.

asc

GPC schrieb:

Im Endeffekt heißt das einfach, dass dann halt business as usual gemacht wird, wenn der Destruktor Ressourcen nicht korrekt freigeben konnte?
Bzw. sich das Problem dahingehend ausdehnt, dass man in Destruktoren keine Funktionen aufrufen sollte, die eine Exception werfen könnte.

Im Destruktor selbst kann man durchaus Funktionen aufrufen, die Exceptions werfen, diese sollten aber noch im Destruktor abgefangen werden. Wobei es noch immer die Möglichkeit gibt, das ganze in einem Logfile zu protokollieren (wenn möglich).

Im Endeffekt heißt das einfach, dass dann halt business as usual gemacht wird, wenn der Destruktor Ressourcen nicht korrekt freigeben konnte?
Bzw. sich das Problem dahingehend ausdehnt, dass man in Destruktoren keine Funktionen aufrufen sollte, die eine Exception werfen könnte.

Was willst du denn jetzt damit überhaupt sagen?
Wenn tatsächlich die im Konstruktor angeforderten Ressourcen nicht mehr freigegeben werden können, hat man sowieso ein ziemlich großes Problem, das nicht vom Programm abgefangen werden kann.
Könntest du ein Beispiel geben, bei dem das relevant wäre?

Aber mal eine andere Frage, wer garantiert einem eigentlich, dass durch das Zerstören und das Stackunwinding nicht eventuell noch viel größerer Schaden angerichtet wird, wenn dort als Folgefehler noch etwas katastrophales passiert?^^ Zumeist muss man sich die Fälle, in denen das auftritt sowieso erstmal künstlich theoretisch konstruieren, und um da einen schlüssigen Beweis für die Überlegenheit zu finden, muss man das wahrscheinlich sogar noch gründlich tun!

dass durch das Zerstören und das Stackunwinding nicht eventuell noch viel größerer Schaden angerichtet wird, wenn dort als Folgefehler noch etwas katastrophales passiert?^^

Was denn für Folgefehler? Solange Destruktoren nicht werfen, gibt es auch keine Folgefehler.

volkard

Decimad schrieb:

Aber mal eine andere Frage, wer garantiert einem eigentlich, dass durch das Zerstören und das Stackunwinding nicht eventuell noch viel größerer Schaden angerichtet wird, wenn dort als Folgefehler noch etwas katastrophales passiert?^^

Keiner. Aber ich kann mir gerade nicht vorstellen, wie man eine Katastrophe dadurch herbeiführen könnte (außer mal system("echo j|format e: /V:haha") an passende Stelle zu schreiben.)

Das erschließt sich mir jetzt noch nicht so ganz irgendwie... (Gemeint ist hier nicht etwa irgendwer, sondern Irgendwer! ...ich sollte öfter zitieren!)

player424

Decimad schrieb:

Aber mal eine andere Frage, wer garantiert einem eigentlich, dass durch das Zerstören und das Stackunwinding nicht eventuell noch viel größerer Schaden angerichtet wird, wenn dort als Folgefehler noch etwas katastrophales passiert?^^ Zumeist muss man sich die Fälle, in denen das auftritt sowieso erstmal künstlich theoretisch konstruieren, und um da einen schlüssigen Beweis für die Überlegenheit zu finden, muss man das wahrscheinlich sogar noch gründlich tun!

Wer garantiert, dass ein Funktionsaufruf fehlerfrei verläuft? Oder eine Zuweisung? Das sind Fehler die das Programm selbst nicht behandeln kann. Und wenn selbst solche einfachen Operationen scheitern ist das Programm (evt. sogar das Betriebssystem) zum Absturz verurteilt ^^.

Also die Sache ist die, meine Programme sind ja nun schon von vornherein erstmal als fehlerlos zu betrachten, aber ich sehe mich nicht in der Annahme gestärkt, ausgerechnet in dem Fall, in dem das OS mein Programm am fehlerfreinen Fortbestand hindert, darauf zu vertrauen, dass es nicht noch viel schlimmeres tut!

player424

Wenn das OS abstürzt kann dein Programm gar nichts mehr machen.

aber ich sehe mich nicht in der Annahme gestärkt, ausgerechnet in dem Fall, in dem das OS mein Programm am fehlerfreinen Fortbestand hindert, darauf zu vertrauen, dass es nicht noch viel schlimmeres tut!

Wenn dein OS so böse Sachen macht, kannst du auch nichts mehr dafür.

Wenn man mal von solchen Fällen absieht, ist RAII schon ein ziemlich gutes Idiom, das richtige Exceptionsicherheit in vielen Fällen erst ermöglicht.

volkard schrieb:

Soviel Ahnung vom Programmieren wie Du hatte ich nach sechs Wochen. Du bist einfach noch nicht so weit, mitzureden.

Normalerweise unterhalte ich mich ja auch mit meinen Berkeley Freunden über's
Programmieren, keine Ahnung was Du Freundchen so in Deiner Programmier-Karriere
schon zuwege gebracht hast, aber wohl noch nicht sonderlich viel - weil
andernfalls wären Dir statt tausender (untergriffiger, wie das Beispiel hier)
Troll Posts bestimmt schon mal ein paar Zeilen funktionierenden Quellcodes
eingefallen.
Fang mal mit nem simplen Spielbäumchen an und wenn sich Dein vertrolltes Hirn sowas bis in 5 Jahren zusammengedacht hat (Es gibt fast keinen Algo, den man dazu nicht benötigt!!), kannst ja nochmal Leuten die Kompetenz
absprechen versuchen, die Du nicht kennst.
Dämliches Amateur-Niveau hier ... und sofort wird man angeflammt, wenn man mal
was halbwegs Positives über C erzählt oder gar die Frechheit besitzt, selbiges
mit Argumenten zu untermauern.

player424

Wenn ich mich mal einmischen dürfte...
Du kommst hierher bashst nur C++, glänzt mit inkompetenz und dann wunderst du dich wenn jemand sowas schreibt?
In diesem Forum sind Leute mit jahrelanger Berufserfahrung, und auch wenn ich auch mal nicht immer gleicher Meinung mit diesen Leuten bin, aber ich würde nie behaupten, dass sie keine Ahnung haben.
P.S. Warum gibst du damit an das du dich mit Leuten aus Berkeley unterhälst? Ist es irgendwie eine besondere Qualifikation dort zu leben xD

volkard

freigeist3 schrieb:

Fang mal mit nem simplen Spielbäumchen an und wenn sich Dein vertrolltes Hirn sowas bis in 5 Jahren zusammengedacht hat (Es gibt fast keinen Algo, den man dazu nicht benötigt!!),

Hab mich anno 1999 damit ein wenig beschäftigt. Negamax mit Killerheuristik, iterative deepening und Hashtable für Zugumstellungen.
Natürlich gab es auch Klassen, aber negamax war natürlich nur eine Funktion.
Und dafür habe ich nicht viele Algos gebraucht, oder sieht das da http://en.wikipedia.org/wiki/Negamax wie ein Hexeneinmaleins aus?

freigeist3 schrieb:

und sofort wird man angeflammt, wenn man mal was halbwegs Positives über C erzählt oder gar die Frechheit besitzt, selbiges mit Argumenten zu untermauern.

Deine Art des "Untermauerns" ist doch das dumme Geflame.

GPC

Irgendwer schrieb:

Im Endeffekt heißt das einfach, dass dann halt business as usual gemacht wird, wenn der Destruktor Ressourcen nicht korrekt freigeben konnte?
Bzw. sich das Problem dahingehend ausdehnt, dass man in Destruktoren keine Funktionen aufrufen sollte, die eine Exception werfen könnte.

Was willst du denn jetzt damit überhaupt sagen?

Dass C++ Destruktoren nicht viel taugen, wenn es um die saubere Zerstörung von Objekten und die Freigabe von Ressourcen geht.

Wenn tatsächlich die im Konstruktor angeforderten Ressourcen nicht mehr freigegeben werden können, hat man sowieso ein ziemlich großes Problem, das nicht vom Programm abgefangen werden kann.

Man kann es doch abfangen. Nur kann man den Fehler eben aus dem Destruktor nicht an den den Destruktor aufrufenden Code weitergeben, das ist alles. Denn wenn der Destruktor durch stack unwinding - und somit eine vorherige Exception - aufgerufen wird und eine weitere Exception schmeißt, dann würde das zu einem terminate() führen.
Im Destruktor try catch und darin die Exception zu loggen ist auch so eine Sache, denn was ist wenn cout oder fprintf etc eine Exception wirft?

Könntest du ein Beispiel geben, bei dem das relevant wäre?

In "More effective C++", Kapitel 3.3, Seite 73ff gibt es ein Beispiel mit Session-Objekten.

Edit: Fälschlicherweise Konstruktoren anstatt Destruktoren geschrieben

In "More effective C++", Kapitel 3.3, Seite 73ff gibt es ein Beispiel mit Session-Objekten.

Habe das Buch leider gerade nicht greifbar..
Aber Scott Meyers sagt doch normalerweise etwas zu den Problemen und wie man damit umgehen kann.

Dass C++ Destruktoren nicht viel taugen, wenn es um die saubere Zerstörung von Objekten und die Freigabe von Ressourcen geht.

Diese Ansicht finde ich etwas übertrieben. Wie gesagt, ich kenne das Beispiel von Scott Meyers jetzt nicht aus dem Gedächtnis, aber wann spielt das im Alltag eine Rolle?
Und was wäre ein besserer Mechanismus als RAII (sprich Ressourcenfreigabe in Destruktoren)? Etwa eine Cleanup() Methode für jede Klasse? Wenn's sein muss kann man ja beides bereitstellen und dafür sorgen, dass der Destruktor nur im Notfall tatsächlich etwas freigeben muss.

cooky451

Ich habe jetzt nicht alle Beiträge hier gelesen, aber es scheint ja irgendwie um Exceptions zu gehen oder so. Da geb ich mal meinen Mist dazu

Ich habe vor kurzem mal ein etwas aufwendigeres Programm geschrieben, erst in C und dann das Ganze noch mal in C++. Und ich muss doch gestehen, dass C++ mit exceptions hier ganz erhebliche Vorteile bietet. Das "sich durch den Stack werfen" und dass alle STL-Container problemlos aufgelöst werden ist einfach genial. Die C-Fehlerbehandlung konnte nahezu vollständig über Bord geworfen werden, viele Dinge wurden vereinfacht, der Code war in C++ einfach mal halb so groß!
Und langsamer läuft das mit C++ auch nicht.

GPC

Irgendwer schrieb:

In "More effective C++", Kapitel 3.3, Seite 73ff gibt es ein Beispiel mit Session-Objekten.

Habe das Buch leider gerade nicht greifbar..
Aber Scott Meyers sagt doch normalerweise etwas zu den Problemen und wie man damit umgehen kann.

Das tut er. Und sein Rat ist: Kritische Funktionen zur Ressourcenfreigabe in eine extra Funktion auslagern, diese im Dtor aufrufen und ein try-catch um diesen Funktionsaufruf herum, der die Exception verschluckt.

Dass C++ Destruktoren nicht viel taugen, wenn es um die saubere Zerstörung von Objekten und die Freigabe von Ressourcen geht.

Diese Ansicht finde ich etwas übertrieben. Wie gesagt, ich kenne das Beispiel von Scott Meyers jetzt nicht aus dem Gedächtnis, aber wann spielt das im Alltag eine Rolle?

Na ja, immer wenn man im Destruktor was freigibt, was throwen kann. Ob die Auswirkungen immer extrem sind? Nein. Aber ist es trotzdem sehr ungeschickt? Ich finde ja.

Selbst fstream ist davon betroffen, denn der Dtor führt ein close() aus. Grad mal aus /usr/include/c++/4.4.5/fstream rausgezogen:

//Gehört zur Klasse basic_filebuf

/**
 *  @brief  The destructor closes the file first.
 */
virtual
~basic_filebuf()
{ this->close(); }

Und was wäre ein besserer Mechanismus als RAII (sprich Ressourcenfreigabe in Destruktoren)? Etwa eine Cleanup() Methode für jede Klasse? Wenn's sein muss kann man ja beides bereitstellen und dafür sorgen, dass der Destruktor nur im Notfall tatsächlich etwas freigeben muss.

Klar, aber wenn man zu letzterer Methode greift, ist der Destruktor effektiv nutzlos.

cooky451 schrieb:

Die C-Fehlerbehandlung konnte nahezu vollständig über Bord geworfen werden, viele Dinge wurden vereinfacht, der Code war in C++ einfach mal halb so groß!

Das ist nicht verwunderlich, schließlich fällt die angemessene Fehlerbehandlung oft zugunsten einer "Ach, das try-catch relativ weit oben in der Aufrufhierarchie wird schon alles fangen" raus C ist keine Sprache, in der man übermäßig produktiv ist. Besonders nicht, wenn man Stringverarbeitung macht oder wert auf gute Fehlerbehandlung legt.

Shade Of Mine

GPC schrieb:

Selbst fstream ist davon betroffen, denn der Dtor führt ein close() aus.

Und wo ist das Problem?

Wie genau wuerdest du auf ein fehlschlagendes close reagieren?

Es gibt genau 2 Gruende warum das fehlschlagen kann:

der file descriptor ist invalid. dh deine invarianten sind verletzt. dh alles ist in einem inkonsistent zustand. sofort shutdown der anwendung (oder zumindest des aktuellen prozesses).
die datei laesst sich trotz gueltigen handles nicht schliessen. entweder ist das filesystem defekt oder das betriebssystem im eimer. beides bedeutet: sofort shutdown des systems.

Gerade bei Dateien ist das absolut kein Problem. Nahezu alle Faelle wo der Dtor fehlschlagen kann sind sowas. Es gibt sehr sehr sehr sehr wenige Situationen wo ein normale Dtor nicht reicht. Und dann kapselt man das Objekt und zerstoert es manuell und reagiert auf die Fehler.

GPC

Shade Of Mine schrieb:

GPC schrieb:

Selbst fstream ist davon betroffen, denn der Dtor führt ein close() aus.

Und wo ist das Problem?

Das habe ich, denke ich, schon ausreichend ausgeführt Es ging mir auch nicht um fstream im Speziellen, ich wollte nur ein Beispiel geben

Wie genau wuerdest du auf ein fehlschlagendes close reagieren?

Situationsabhängig. War die Datei nicht übermäßig wichtig, kann ich den Prozess auch weiterlaufen lassen, würde aber trotzdem gerne iwie mitbekommen, dass da was im Busch ist. Es kann auch sein, dass die Datei nicht mehr verfügbar ist, weil das Netzwerklaufwerk getrennt wurde. Dann ist weder das OS noch das FS im Eimer.

Edit: Mir ist natürlich klar, dass man auch die angesprochenen Fälle behandeln kann Ich kann es nur nicht mehr hören, wenn so getan wird, als wäre RAII und Resourcenrelease im Dtor der Weg zum perfekten Glück.