Brauche Hilfe beim Umschreiben von Java Programm in C++

[Nasenbaer]

Hi,
ich hab vor kurzem nen kleinen Raytracer in Java geschrieben und will den jetzt in C++ umschreiben und dann einige Arbeiten per CUDA beschleunigen.

Aber aber erstmal beim umschreiben einige Probleme. In java hab ich immer intensiv die eingebauten Exceptions (NullPointerException, IllegalArgumentException, etc.) genutzt und finde sowas aber nicht in Bibliotheken für C++ - hab dazu in der STL nichts gefunden und in Boost auch nicht. Habe aber nicht wirklich Lust, dass alles selbst neu zu erfinden.
Gibt es da irgendwas fertiges, dass man gut nutzen kann?

[DavChrFen]

was benutzt du für einen Compiler?

[Nasenbaer]

was benutzt du für einen Compiler?
Ich nutze Visual Studio 2005 (x64).

[Gast]

Diese Frage interessiert mich auch. Wie wird das Exception Handling (das man als Java programmierer gewohnt ist) in C++ oder in C# umgesetzt?

Sowas muss es doch geben?

[Der_Donnervogel]

Diese Frage interessiert mich auch. Wie wird das Exception Handling (das man als Java programmierer gewohnt ist) in C++ oder in C# umgesetzt?

Sowas muss es doch geben?Das geht auch, wobei ich mich mit C++ viel zu schlecht auskenne um eine genaue Antwort zu geben. C# unterscheidet sich nicht dramatisch von Java was Exceptions angeht. Der Hauptunterschied liegt darin, dass man bei C# Exceptions nicht fangen muss sondern nur kann. Bei C# wird man deshalb nicht schon von der IDE gezwungen Exceptions abzuhandeln falls die Methode welche wirft, sondern man muss selber wissen, ob und was man behandeln will. Es wird auch nicht im IDE angezeigt was für Exceptions die Methode wirft, weswegen man meinen könnte, die Methoden werfen gar keine Exceptions wenn man zB von Eclipse kommt, das stimmt aber nicht. Das ist vielmehr so, wie zB eine NumberFormatException bei Java, die ja auch nicht erzwungen wird, aber gefangen werden kann.

[Trap]

In C++ gibt es auch Exception-Handling, in einigen Punkten unterscheidet sich das aber von Java. Es gibt kein finally, es gibt kaum fertige Exception-Typen und für Polymorphie im Exception Typ muss man etwas aufpassen.

[Nasenbaer]

Das geht auch, wobei ich mich mit C++ viel zu schlecht auskenne um eine genaue Antwort zu geben. C# unterscheidet sich nicht dramatisch von Java was Exceptions angeht. Der Hauptunterschied liegt darin, dass man bei C# Exceptions nicht fangen muss sondern nur kann. Bei C# wird man deshalb nicht schon von der IDE gezwungen Exceptions abzuhandeln falls die Methode welche wirft, sondern man muss selber wissen, ob und was man behandeln will. Es wird auch nicht im IDE angezeigt was für Exceptions die Methode wirft, weswegen man meinen könnte, die Methoden werfen gar keine Exceptions wenn man zB von Eclipse kommt, das stimmt aber nicht. Das ist vielmehr so, wie zB eine NumberFormatException bei Java, die ja auch nicht erzwungen wird, aber gefangen werden kann.
In den Compiler-Optionen bei Ecplipse kann man das Erzwingen der Catch-Blöcke auch abschalten soweit ich weiß. Wie sinnvoll sowas bei Programmen ist, die man nicht nur mal ebend schnell zusammenfrickelt ist eine andere Frage.

[maximAL]

Aber aber erstmal beim umschreiben einige Probleme. In java hab ich immer intensiv die eingebauten Exceptions (NullPointerException, IllegalArgumentException, etc.) genutzt und finde sowas aber nicht in Bibliotheken für C++ - hab dazu in der STL nichts gefunden und in Boost auch nicht.
in C++ gibts zwar execptions, leider nutzt sie kaum jemand. in der STL werden sie überhaupt nicht verwendet, wenn du da irgendwelchen blödsinn machst, ist das ergebnis meistens nicht definiert, mit etwas glück haben die entwickler der jeweiligen implementation wenigstens ein paar assertions reingepackt...

[Trap]

in der STL werden sie überhaupt nicht verwendet
Stimmt nicht ganz, iostreams können auf Wunsch Exceptions werfen.

Wer sich schon mal informiert hat, was man alles beachten muss um in C++ exception-safe code zu schreiben, ist über die Standardbibliothek ohne Exceptions auch ganz glücklich.

[Nasenbaer]

Derzeit mach ichs einfach so:

throw "Can't set bla because it is NULL.";


Was besseres fiel mir erstmal nicht ein und da es nicht schon nen fertigen an Exceptions gibt hab ichs nun so gelöst. Da ich das eh nur als Debug-Output nutze und selbst keine Exceptions fange, ist das auch völlig egal. ;D

[ScottManDeath]

Boost hat exception support libraries und nutzt sie auch recht extensiv. Die boost exceptions leiten von std::exception ab.


http://www.boost.org/doc/libs/1_37_0/libs/exception/doc/boost-exception.html

[ollix]

Ich benutze seit einiger Zeit das Poco Framework (http://pocoproject.org). Ist nicht so mächtig wie Boost, finde es aber für die meisten Dinge deutlicher schöner und komfortabler. Bietet auch Exception Support (http://pocoproject.org/poco/docs/Poco.Exception.html) und nutzt diesen auch fleissig; dazu kann über das POCO_IMPLEMENT_EXCEPTION Makro (http://poco.svn.sourceforge.net/viewvc/poco/poco/trunk/Foundation/src/Exception.cpp?view=markup) auch leicht was zusätzliches generiert werden.

[ScottManDeath]

Ich hab mir sowas zusammengebaut

(In auschnitten) http://rafb.net/p/LwoUJS40.html

[SimonX]

Exceptions sollte man in C++ nur für Fehler werfen. Wenn man Exceptions für erwartete häufige Ergebnisse wirft, dann ist C++ viel langsamer als wenn man z.B. einen bool-return Wert zurück gibt, der dann durch ein if() geprüft wird. Wir sprechen hier von Faktor 10-50 bei gcc-4.x auf Sparc-CPU's und das ändert sich sicher nicht wesentlich mit der CPU oder dem verwendeten Compiler.

Beispiel: Eine Funktion die etwas finden soll und jedes mal eine Exception wirft, wenn nichts gefunden wurde. Wenn erwartet wird, das man häufig unbekannte Anfragen bekommt, dann ist eine Exception over-overkill.

[The_Invisible]

exceptions sind eh für weicheier. :biggrin:

finde es in java auch immer nervig wenn man etwas abfangen muss, außerdem ist es langsam.

mfg

[ScottManDeath]

Hast Du Benchmarks die belegen das Exceptions langsam sind?

Hast Du Benchmarks die belegen das Fehlerhandling mittels return codes robusteren und einfacher wartbaren Code zur Folge haben?

[Laz-Y]

Naja, ich seh die Exeptions als einen großen Vorteil von Java @ Invisible. Kann aber jeder programmieren wie er will ;)

[Trap]

Naja, ich seh die Exeptions als einen großen Vorteil von Java
Konkurrenten von Java wären am ehesten C# oder C++ und beide haben so gut wie identische Exceptions. Eventuell kann man es als Vorteil gegenüber C zählen...

Das condition handling system von Common Lisp ist eine Generalisierung von Exceptions und erlaubt schwächere Kopplung der beteiligten Komponenten.

[Laz-Y]

Den Vorteil sehe ich darin, dass ich Exception bei Java fangen muss.

[Monger]

Hast Du Benchmarks die belegen das Exceptions langsam sind?

Exceptions sind in der Tat ziemlich komplex. Afaik arbeiten die mit Reflections, um den Stacktrace aufzulösen, und das ist nicht gerade sehr performancestark.

Aber Exceptions sollten ja auch nunmal eher AUSNAHMSWEISE auftreten, und nicht etwa zur Signalisierung mißbraucht werden. Und dann ist die Performance natürlich herzlich egal.


Hast Du Benchmarks die belegen das Fehlerhandling mittels return codes robusteren und einfacher wartbaren Code zur Folge haben?
Ich glaub, das kann man sogar klar widerlegen. Error Codes müssen ausgewertet werden, selbst wenn 99% der Zeit alles richtig läuft. Deshalb dürfte für 99% aller Fälle gutes Exception Handling den Code sogar schneller machen.

Edit: btw. , ich finde die Compile-Zeit Exceptions von Java eine ziemlich klevere Idee. Damit wird man direkt beim Aufruf schon dazu gezwungen, sich Gedanken über Randbedingungen zu machen. Dass andere Sprachen wie C# das bisher nicht adaptiert haben, überrascht mich ein wenig.

[pest]

Ich glaub, das kann man sogar klar widerlegen. Error Codes müssen ausgewertet werden, selbst wenn 99% der Zeit alles richtig läuft.

Geheiligt sei die Sprungvorhersage

[Coda]

Auch Exceptions werden nur bei bestimmten Bedingungen geworfen.

Aber trotzdem ist das Quatsch. Die Sprungvorhersage ist nur der letzte Rettungsanker und funktioniert lang nicht so gut wie du dir das vorstellst. Vor allem wenn man über Code redet der nicht oft aufgerufen wird.

[pest]

Die Sprungvorhersage ist nur der letzte Rettungsanker


ist schon ne weile her seit ich das mit asm getestet habe, aber es geht ja um sowas hier


ret = dosomething(bla)
if (ret!=0) dosomethingelse()


und da hat das wunderbar funktioniert


und funktioniert lang nicht so gut wie du dir das vorstellst.


wenn zu 99% bei obigem Beispiel ret=0 ist, und die Schleife nicht zu lang ist, funktioniert sie ganz gut, ja so stelle ich mir das vor ;)



Vor allem wenn man über Code redet der nicht oft aufgerufen wird.

dann ist der Performancehit m.M. nach auch egal

[ScottManDeath]

Aber Exceptions sollten ja auch nunmal eher AUSNAHMSWEISE auftreten, und nicht etwa zur Signalisierung mißbraucht werden. Und dann ist die Performance natürlich herzlich egal.


Eben :) Ich hab in meinem Raytracer zum Debuggen irgendwo tief im Tree Exceptions geworfen um dann den in der Exception gespeichterten Farbwert in den Pixel zu malen. Aber das war eh nur zum, Debuggen.


Ich glaub, das kann man sogar klar widerlegen. Error Codes müssen ausgewertet werden, selbst wenn 99% der Zeit alles richtig läuft. Deshalb dürfte für 99% aller Fälle gutes Exception Handling den Code sogar schneller machen.

Klar, aber ich meinte ja die Wartbarkeit. Wenn ich 20% weniger Zeit brauche um etwas zu entwickeln, was zwar 120% mehr Laufzeit benoetigt, dann hilft mir Moores Law, ganz zu schweigen dass ich z.B. in 5 Jahren es einfacher habe, ueberschaubaren Code zu warten/erweitern.

Klar sollte man in rechenintensiven Sachen da aufpassen, aber der wenigste Teil eines Programmes cruncht mit 100% CPU Last ;)

Und Error Codes sind raeudig, weil man genau dann gebissen wird, wenn man einen Fehler nicht abruft, bzw man bekommt den Errorcode dann, x Funktionsaufrufe spaeter :(

Ich hab mir extra ein Set von Makros gebaut damit ich im Debug Mode nach fast jedem OpenGL aufruft glGetError aufrufe und in eine Exception umwandle. Im Release Mode mach ich dann glGetError nur nach kritischen sachen wie z.B. ShaderCompile oder Texturallozierung, bzw einmal pro Frame.


Edit: btw. , ich finde die Compile-Zeit Exceptions von Java eine ziemlich klevere Idee. Damit wird man direkt beim Aufruf schon dazu gezwungen, sich Gedanken über Randbedingungen zu machen. Dass andere Sprachen wie C# das bisher nicht adaptiert haben, überrascht mich ein wenig.

http://herbsutter.wordpress.com/2007/01/24/questions-about-exception-specifications/

[mekakic]

Ich hab mir extra ein Set von Makros gebaut damit ich im Debug Mode nach fast jedem OpenGL aufruft glGetError aufrufe und in eine Exception umwandle. Im Release Mode mach ich dann glGetError nur nach kritischen sachen wie z.B. ShaderCompile oder Texturallozierung, bzw einmal pro Frame.
Wie sieht sowas in etwa aus?