C++ Community

pock

AGS'ler schrieb:

# define try      if (true)
# define catch(X) if (false)

try
{
   foo();
} 
else
{
   bar();
}

AGS'ler schrieb:

Wie, dass ich diese Version habe?^^

Nee, ich hatte letztens einen Disput. Es ging um die Differenz zwischen dem was ich von der Cpp Laufzeitumgebung in Punkto Benutzerfreundlichkeit erwartet hatte und dem was ich bekommen habe.

Artchi

try und catch sind definitiv keine Makros in C++ sondern ein essenzieller Bestandteil der Sprachnorm. Es sind Schlüsselwörter wie if, class usw.

Wenn devcpp eine header mit solchen Makros hat, kann C++ nichts dafür! Das ist eine Entscheidung der devcpp-Jungs. Besorgt euch vernünftige Compiler und IDEs, die den C++-Standard vernünftig umsetzen, anstatt irgendwelche Workarounds hier zu posten.

Julian__

da kann ich nur zustimmen.
diese defines sehen wirklich wenig sinnvoll aus ... wozu braucht man sowas?
um leute zu verwirren, die das in nem header benutzen und versuchen, exceptions zu behandeln?

mfg,
julian

Artchi schrieb:

Besorgt euch vernünftige Compiler und IDEs, die den C++-Standard vernünftig umsetzen, anstatt irgendwelche Workarounds hier zu posten.

Ja Meister, ich werde gehorchen, wenn du mir einen vernünftigen nennst!!!

Visual Studio C++

-> Kostenlose Express Version. Wie wäre es damit? Für den Anfang

Bemüh mal Google

joomoo

Oder auch Code::Blocks.

piXelshooter

AGS'ler schrieb:

Artchi schrieb:

Besorgt euch vernünftige Compiler und IDEs, die den C++-Standard vernünftig umsetzen, anstatt irgendwelche Workarounds hier zu posten.

Ja Meister, ich werde gehorchen, wenn du mir einen vernünftigen nennst!!!

meinst, mingW ist kein guter compiler?

joomoo

piXelshooter schrieb:

AGS'ler schrieb:

Artchi schrieb:

Besorgt euch vernünftige Compiler und IDEs, die den C++-Standard vernünftig umsetzen, anstatt irgendwelche Workarounds hier zu posten.

Ja Meister, ich werde gehorchen, wenn du mir einen vernünftigen nennst!!!

meinst, mingW ist kein guter compiler?

Nicht in der Version die bei Dev-C++ dabei ist, oder?

piXelshooter

ist doch die gleiche wie die standalone version? ich hab beide drauf und auf beiden funzt alle s wunderbar...auch exceptions^^

*edit* auch mingW normal hat diese datei (beide male mingW version 3.4.2)

hustbaer

Vermutlich includiert man diese ominöse "exception_defines.h" normalerweise einfach nicht (auch nicht indirekt)? Wäre das vielleicht möglich (ich kenne mingW nicht!)?

Xin

Julian__ schrieb:

da kann ich nur zustimmen.
diese defines sehen wirklich wenig sinnvoll aus ... wozu braucht man sowas?
um leute zu verwirren, die das in nem header benutzen und versuchen, exceptions zu behandeln?

Annahme: Mein Programm stürzt nicht ab, weil es Exceptions sauber abarbeitet werden.
Aber irgendetwas funktioniert nicht ganz wunschgemäß.

Also einfach mal abschmieren lassen und gdb fragen, wo es geknallt hat. Anschließend weiß man, in welchem try-Block man vielleicht nochmal ran sollte.
Am einfachsten wäre das, wenn try und catch genauso funktionieren würden, wie es diese Macros beschreiben.

Wäre jetzt mal meine Idee. Ich gehöre nicht unbedingt zur Fan-Gemeinde der Exceptions, ergo wenig try..catch, ergo kein derartiger Header. Meine Algorithmen müssen so formuliert sein, dass keine Ausnahmen existieren, die man abfangen müsste.

hustbaer

@Xin:
Huh?
Wie kommst du darauf dass das "entfernen" von try und catch dazu führen würde dass das Programm dort crasht wo irgendein "nicht ganz so wie es sollte" zu finden ist? Klar kann es sein dass das manchmal der Fall ist, aber viele Programme verwenden Exceptions in einigen Fällen die auch beim normalen Arbeiten öfters mal vorkommen können. Wogegen auch nix einzuwenden ist. Wenn die dann nicht dort gefangen werden wo sie gefangen werden sollten geht das Programm u.U. schon VOR dem eigentlichen Problem ganz andere Wege als es gehen sollte.

Und BTW (nur aus interesse): was für Programme/Algorithmen schreibst du denn dass du ganz auf Exceptions verzichten kannst?

Dem "wenig try-catch" kann ich mich zwar anschliessen, aber das heisst nicht unbedingt auch "wenig throw". Anders gesagt: in meinen Programmen fange ich auch nicht andauernd irgendwo sinnlos Exceptions, aber es werden an vielen Stellen welche geworfen, einfach weil es so viele Dinge gibt die schief gehen könnten, es aber im Normalfall nicht tun (Speicher anfordern, Files aufmachen, in Files lesen/schreiben, sonstige Resourcen anfordern etc.). "Viel try-catch" ist IMHO ein Hinweis auf den Missbrauch von Exceptions, oder darauf dass jmd. zu faul war Guards zu schreiben. "Wenig throw" dagegen ist IMHO (zumindest in "low-level" Code) ein Hinweis darauf dass jemand zu faul war auf mögliche Fehler zu prüfen und diese entsprechend zu behandeln.

Shinja

Ist das was Xin beschreibt nicht das, was assert macht? (bisschen OT, sry)

Also ich stimme 100%-ig mit hustbaer überein!

PS: Ich liebe dieses Forum!!!

Ben04

Vielleicht sollte man die vollständige Headerdatei mal posten :

/*[copyright]*/
#ifndef _EXCEPTION_DEFINES_H
#define _EXCEPTION_DEFINES_H 1

#ifndef __EXCEPTIONS
// Iff -fno-exceptions, transform error handling code to work without it.
# define try      if (true)
# define catch(X) if (false)
# define __throw_exception_again
#else
// Else proceed normally.
# define __throw_exception_again throw
#endif

#endif

(http://www.koders.com/c/fidE0577C0A935358E6976648FF49F8522993DDE8B7.aspx)

Dieser Code wird der libstdc++ benutzt. Sie ist nicht wirklich dazu gedacht von Programmierer benutzt zu werden und dient viel mehr dazu, dass man die STL nicht zweimal coden muss : einmal mit Ausnahmen und einmal ohne.

Irgendwie witzig wie hier alle auf DevC++ rumreiten... Sogut wie jeder g++ hat die Datei irgendwo.

Besorgt euch vernünftige Compiler und IDEs, die den C++-Standard vernünftig umsetzen, anstatt irgendwelche Workarounds hier zu posten.

Compiler ist definitive vernünftig solange man nicht auf die neusten MS Mode-APIs Zugriff braucht. IDE war in der letzten Version die ich ausprobiert habe recht unstabile ist aber auch schon über 2 Jahre her. Da kann sich viel getan haben.

Ist das was Xin beschreibt nicht das, was assert macht? (bisschen OT, sry)

assert testet eine Bedingung nur im Debugmode und schmiert ab wenn sie nicht stimmt. Sehr nützlich um Logik Bugs frühzeitig zu finden.

int foo = ...;
int bar = my_sqrt(foo);
assert(bar >= 0); // Wenn das nicht stimmt ist etwas faul!

Xin

hustbaer schrieb:

@Xin:
Wie kommst du darauf dass das "entfernen" von try und catch dazu führen würde dass das Programm dort crasht wo irgendein "nicht ganz so wie es sollte" zu finden ist?

'throw' ohne 'catch' = Fullstop.
Bei Einbinden dieses Headers gibt es kein catch mehr.
Ich denke, dass sich die Frage wer in unhandled_exception() [genauen Namen hab' ich vergessen] landet mit gdb verfolgen lassen müsste - ich habe den Header allerdings auch noch nicht gesehen und es nie ausprobiert.

hustbaer schrieb:

Klar kann es sein dass das manchmal der Fall ist, aber viele Programme verwenden Exceptions in einigen Fällen die auch beim normalen Arbeiten öfters mal vorkommen können. Wogegen auch nix einzuwenden ist.

Wenn dagegen nichts einzuwenden ist, dass Exceptions beim normalen Arbeiten auftreten, dann frage ich mich, warum man sie "exception" statt "condition" nennt.

hustbaer schrieb:

Und BTW (nur aus interesse): was für Programme/Algorithmen schreibst du denn dass du ganz auf Exceptions verzichten kannst?

Eigentlich querbeet. Projekte letzter Jahre waren ein visuell programmierbares Bildbearbeitungsprogramm, einige DLLs, um Algorithmen für Labview zu optimieren, ein Framework für Datenbankzugriffe, das unter anderem auch Nicht-SQL-Datenbanken SQL-fähig machte, etwas .COM-Programmierung, ein paar Webprojekte und mein persönlicher Favorit ist eine Programmiersprache mit dazugehörigen Compiler.
Für letztes gibt's leider kein Geld, das ist quasi Hobby.
Ich schrieb' meine Diplomarbeit über Programmiersprachen.

Wenn Exceptions nicht wie bei Java zwingend vorgeschrieben sind, kann man darauf recht gut verzichten. Bei Java könnte ich das auch, denn das hakt auch. Beipspiel: Mein Programm wurde in Java 1.4 geschrieben und kompiliert. Nun wirft Java 1.5 mir etwas Neues zwischen die Beine. Dann gibt's meine Lieblingsmeldung: "Ausnahme, Programm beenden, Daten futsch, versuch's doch nochmal ^^' und dem darf ich dann mit "Ok" meinen Segen geben?
Cool...

hustbaer schrieb:

"Viel try-catch" ist IMHO ein Hinweis auf den Missbrauch von Exceptions, oder darauf dass jmd. zu faul war Guards zu schreiben. "Wenig throw" dagegen ist IMHO (zumindest in "low-level" Code) ein Hinweis darauf dass jemand zu faul war auf mögliche Fehler zu prüfen und diese entsprechend zu behandeln.

Mein Lieblingsbeispiel hierzu ist die sqrt-Funktion. Man kann einen Wert übergeben und der könnte kleiner 0 sein.
Also frage ich in der sqrt-Funktion ab, ob der Wert >= 0 ist, sonst werfe ich eine passende Exception.
So weit, so schlecht.
Das tue ich nach dem Funktionsaufruf (der kostet Zeit), vor dem Funktionsaufruf muss ich erstmal mitteilen, dass ich meine Exceptions nun gerne wo anders kontrollieren möchte - auch 'try' ist nicht kostenlos, genausowenig wie die '}' am Ende von 'try'. Dann die Frage ob der (Wert >= 0) ist, kostet Zeit und ist dem nicht so, so wirft man eine Exceptions, die im passenden 'try'-Block erstmal gesucht werden muss und wenn man sie nicht findet, sucht man halt im überordneten Block weiter und sucht und sucht... alles schön zur Laufzeit.

Das alles lässt sich verhindern, wenn der Algorithmus, der sqrt() ruft, diese Information vorher abfragt - sofern es ihn überhaupt interessiert. Reagieren muss er sowieso. Die Abfrage muss vor oder während des sqrt()-Aufrufs sein. Entweder reagiert er in else (was fast nichts kostet) oder in catch (was sehr teuer ist). Wenn alles perfekt läuft, ist 'try' günstig - aber immernoch teurer als die Guards.

Warum könnte es einen Algorithmus nicht interessieren, ob sqrt() richtig gefüttert wird?
Möchte ich die Länge eines Vectors berechnen, bekommt sqrt() die Summe von quadrierten Ausrücken. Eine Abfrage ist an allen Stellen vollkommen sinnlos, da die Summe von quadrierten Ausdrücken niemals < 0 sein kann. Der Funktionsaufruf kann nicht fehlschlagen. Jede Frage, ob er fehlschlagen könnte, ist eine Frage zuviel.
Ist die Abfrage in sqrt() fest verdrahtet und ich brauche sqrt ein paar Millionenmal, dann stelle ich ein paar Millionen Fragen zuviel und kann es nicht abstellen.
Darum lernt oder studiert man Programmieren. Auf sowas achtet aber nicht jeder? Es sollte auch nicht jeder Programme schreiben, denn Programmiersprachen geben Konstrukte, die Wissenden unterstützen. Wer keine Ahnung hat, kann jede Sprache programmieren, keine Sprache macht daraus ein gutes Programm.

Ich finde es vollkommen in Ordnung, dass eine Funktion mit illegalen Parametern auch undefinierte Rückgaben hat. Das kann in der Entwicklungszeit ein assert() lösen.
Exceptions in den Normalfall einzubeziehen (FileNotFound)... das gibt nur Beißspuren in meiner Tischkante.
Ein ArrayOutOfBounds ist ein Fehler im Algorithmus und alles andere als eine Ausnahme. Jedes Array hat einen Anfang und ein Ende - das ist normal. Das zur Ausnahme zu erklären kostet sinnlos jede Menge Rechenleistung.

Ich verstehe nicht den Nutzen einen Mangel im Algorithmus zur Anwender-Laufzeit zur Diskussion zu stellen. Das Programm soll abschmieren und der Entwickler soll sich hinsetzen und überlegen, was er zu tun hat, damit das Programm nicht abschmiert.

Mir hilft die inzwischen recht üblich gewordene Meldung "Eine Ausnahme ist aufgetreten, bitte starten Sie das Programm erneut" nicht. Ich finde es ehrlich gesagt vollends daneben, wenn ich vor einem Programmabsturz auch noch lesen darf, dass es abgestützt ist. Ich verstehe den Vorteil nicht, wenn sich ein Programm unkontrolliert beendet oder wenn es unkontrolliert zu einer Meldung kommt, die mich den Verlust meiner Daten erst bestätigen lässt.

Der Aufbau von Exceptions ist so, dass im Falle eine Ausnahme, sehr teuer herausgefunden werden muss, was passiert ist. Dafür bleibt der Algorithmus in einem Stück und leicht zu lesen (Vorteil) - außer wenn an zwei Stellen die gleiche Exception geworfen werden könnte und wer weiß schon immer so genau, welche Exception von wem geworfen werden kann!? (Hmm... doch kein Vorteil?) Dann läßt sich nämlich nichts mehr herausfinden und im Murphys Idealfall glaubt der Entwickler Exception X wird nur an einer bestimmten Stelle geworfen und doktert dann 2 Tage daran herum, weil der Fehler woanders herkommt.
Diese "Wo?" Information ist genau da kostenlos verfügbar, wo etwas schief gegangen ist.
Man wirft diese kostbare und doch kostenlos verfügbare "Wo?"-Information dann lieber weg und begnügt sich mit einer sehr teuren "Was?"-Information, obwohl "Wo?" in der Regel ausreichend ausdrückt "Was" für ein Datensatz nicht verfügbar ist und warum das Programm hier grade die Grätsche macht.

Die Idee von Exceptions ist gut, aber entweder habe ich sie nicht kapiert oder mit Java wurden sie einfach Mode.
Zur Schaustellung von IT-Wissen. Try to throw beeindruckende neue Fachwörter, die der Unwissende und auch meinereiner nicht logisch nachvollziehen kann.

Artchi

Xin! Du hast Exceptions nicht verstanden. Exceptions sind keine Modeerscheinung, sondern lassen einen komplett anderen Workflow zu, den man mit Return-Codes keinesfalls nachahmen kann. Und wenn, dann nur mit viel Aufwand, das man dann gleich Exceptions nehmen kann.

Exceptions fanden schon in CPUs zu Homecomputerzeiten ihren Einsatz (z.B. im Archimedes mit RISCOS, geniales Exceptionshandling mit Assembler über die CPU), bevor es sie in C++ gab. Java gabs zu der Zeit nicht mal.

Ich habe damals zu Assemblerzeiten auch gesagt "Wozu OOP?". Ich wurde durch ERFAHRUNG mit OOP eines besseren belehrt. Genau das fehlt dir mit Exceptions, sonst würdest du nicht versuchen hier ellen lange Postings zu schreiben, um für dich selber eine Rechtfertigung zu finden, warum sie angeblich nicht sinnvoll sein sollen.

Xin

Artchi schrieb:

Xin! Du hast Exceptions nicht verstanden. Exceptions sind keine Modeerscheinung, sondern lassen einen komplett anderen Workflow zu, den man mit Return-Codes keinesfalls nachahmen kann. Und wenn, dann nur mit viel Aufwand, das man dann gleich Exceptions nehmen kann.

Der Aufwand ist identisch mit Exceptions, schließlich muss die gleiche Information implementiert werden. Gegenfrage: Warum dann Exceptions nehmen, wenn Guards optimierter und kostengünstiger sind?

Artchi schrieb:

Exceptions fanden schon in CPUs zu Homecomputerzeiten ihren Einsatz (z.B. im Archimedes mit RISCOS, geniales Exceptionshandling mit Assembler über die CPU), bevor es sie in C++ gab. Java gabs zu der Zeit nicht mal.

Ich habe damals zu Assemblerzeiten auch gesagt "Wozu OOP?". Ich wurde durch ERFAHRUNG mit OOP eines besseren belehrt. Genau das fehlt dir mit Exceptions, sonst würdest du nicht versuchen hier ellen lange Postings zu schreiben, um für dich selber eine Rechtfertigung zu finden, warum sie angeblich nicht sinnvoll sein sollen.

Kein Problem. Ich habe ellenlange Postings mit einer für mich nachvollziehbaren Argumentation.
Du hast den Hinweis, dass Exceptions schon lange existieren.

...und?

Stromschalter existieren auch schon seeehr lange und trotzdem sehen wir das Programmieren über Schalter heutzutage nicht mehr als geeignet an.

Was die Erfahrung angeht: Ich habe in Java und C# mit Exceptions programmiert. Es ist also nicht so, dass ich noch nie damit zu tun gehabt hätte. Gegen OOP habe ich mich nie gestreubt. Im Gegenteil, ich habe schon bevor ich C++ lernte in C OOP programmiert.

Der andere Workflow: Ich ->denke<-, ich verstehe den anderen Workflow ganz gut, daraus entwickelt sich in meinen Augen einige Nachteile. Diese zu wiederholen würde hier wieder zu einem ellenlangen Posting führen. "Du hast keine Ahnung" und "Exceptions gibt's aber schon sooo lange" sind jetzt nicht wirklich ein Grund meine Ansichten zu ändern.
Stattdessen poste doch lieber mal die von mir nicht verstandenen Vorteile von Exceptions. Ich bin offen meine Meinung zu ändern, wenn ich logisch nachvollziehbare Gründe dafür sehe.
Bis dahin suche ich lieber Alternativen und entwickle die Idee Guards weiter.

[quote="XinDu hast den Hinweis, dass Exceptions schon lange existieren.

...und?

Stromschalter existieren auch schon seeehr lange und trotzdem sehen wir das Programmieren über Schalter heutzutage nicht mehr als geeignet an.
[/quote]

Naja Xin, eines deiner Argumente war, das Exceptions nur eine "Modeerscheinung" seien. In dem Zusammenhang finde ich die Aussage, daß es das Konzept der Exceptions schon seit ca 30 Jahren gibt durchaus legitim, denn es führt die "Modeerscheinungs"-Argumentation genau dahin wo sie hingehört, ad absurdum.

An der Stelle merkt man aber auch daß Du ein Fanatiker bist, denn erst argumentierst Du es sei ja nur eine Modeerscheinung (also kurzlebig), wenn dann jemand darauf hinweist das deine "Modeerscheinung" sich nun schon seit 30 Jahren hält ist das auf einmal auch etwas schlechtes. Daher versuch ich auch gar nicht erst etwas andere zu behaupten, denn ich bin mir sicher das Du lieber einen MOnat damit verbringst mir dann beweisen zu wollen das ich falsch liegen muß als auch nur eine Stunde darüber nachzudenken, ob nicht Du vielleicht den Verständnisfehler hast. Und nur weil Du in Java, C# schonmal exceptions benutzt hast, also weisst wie sie technisch Funktionieren heisst das noch lange nciht das Du sie auch auf der Designeben begriffen hast und auch richtig einsetzt. Deine Argumene die Du gegen Exceptions aufführst lassen eher den Schluß zu das Du, wenn Du sie mal benutzt, sie eher falsch benutzt. Aber wie gesagt, solange Du 100% deiner "Resourcen" darauf verbringst allen anderen beweisen zu wollen wie falsch sie liegen und nciht wenigstens mal 1% darauf setzt, den Fehler bei Dir in betracht zu ziehen ist jede Diskussion hier schlicht sinnlos.

Und unterstell mir nicht ich würde Deine Argumente schlicht nciht verstehen... Been there, done that. Ich habe selber lange gebraucht um vom alten return-code Programmieren weg- hin zu exceptions zu kommen. Am Ende habe ich daraus gelernt daß man sich meistens nur selber im weg steht je fanatischer man neue Ideen bekämpft statt aus ihnen zu lernen.

Btw, unsere Computer arbeiten nach wie vor mit dem Konzept der Schalter, nur das die mechanischen Schalter durch elektronische Schalter ausgetauscht wurden, oder was denkst Du ist ein Transistor anderes als ein Schalter? Auch alte Konzepte können gut sein, oft werden Konzepte ja erst dadurch alt, dass sie sich bewährt haben...