Exceptionverwendung in größeren Projekten?
-
Hallo.
Ich werde bald dabei sein, mein Spiel weiterzuprogrammieren.
Exceptions sind ja wunderbar, um Fehler abzufangen etc., aber ich hörte sie seien sehr langsam.
Sind sie nur langsam, wenn man eine wirft?
Dann wärs ja völlig egal :D...
Oder verlangsamt ein try-Block insgesamt das Programm?MfG MAV
-
theoretisch nur lahm, wenn man wirft.
faktisch auch noch code-vergrößerung und solche aspekte, die ganz ohne fehlerbehandlung nicht wären. aber wenn fehlerbehandlung, dann sind exceptions nicht schlecht, denn bei altem c-code würdest du die hälfte des source-codes dafür verwenden müssen.
-
hi,
irgendwo hab ich mal gelesen, dass die Rückkehr aus einer Funktion mit einer Exeption ca. 3 mal so lange dauert wie mit einem normalen return;AFAIK verlangsamt auch der try Block das Programm, weshalb man die Anzahl dieser auf das nötigste reduzieren sollte.
-
Exception sind doch für Ausnahmebehandlung und nicht für Fehlerbehandlung gedacht?
-
Was verstehst du unter einer Ausnahme und was unter einem Fehler?
-
ein Fehler ist (sollte sein) eine Ausnahme.
Aber eine Ausnahme muss kein Fehler sein
-
Hallo,
das hängt sehr stark vom verwendeten Compiler ab. Beim VC 6.0 ist es IMHO so, dass Exceptions relativ teuer sind. Und zwar egal ob geworfen wird oder nicht. Bei neueren Compilern ist das aber wohl nicht mehr der Fall. Hier entstehen die Kosten erst, wenn das Kind in den Brunnen gefallen ist, also wenn eine Exception geworfen wird.Am Ende bleibt einem wohl wieder nur der Griff zur guten alten Stoppuhr
-
hat jemand zeit, mal nachzumessen, damit das IMHO da weggeht?
-
Original erstellt von davie:
ein Fehler ist (sollte sein) eine Ausnahme.
Aber eine Ausnahme muss kein Fehler seinhmm. mach mal beispiel für ne ausnahme, die sinnvollerweise nur ne ausnahme und kein fehler ist.
(bitte nicht in java, da isses üblich.)
-
würde mich auch über die ergebnisse freuen, würde es auch selbst machen nur keine zeit
-
suizid...
äh, ich meine, dann nehm ich lieber net weil vc6.0
-
quatsch. nimm exceptions
-
äh, ich meine, dann nehm ich lieber net weil vc6.0
Falsche Schlussfolgerung. Ehrlich. Nimm eine Stoppuhr (einen Profiler) und miss es nach.
-
Original erstellt von Mis2com:
äh, ich meine, dann nehm ich lieber net weil vc6.0nachdem du gemessen hast bitte. alles andere wäre unfug.
und auch dann nur, wenn der unterschied drastisch ist, denn du wirst ja bald auf nen moderneren compiler umsteigen müssen, und spätestens da gibts kein problem.nur mal angenommen, ein funktionsaufruf sei dreimal so lang. mit alten mitteln müßtest du auf jeden fall den aufruf in ein if stecken und oft sogar nen zusätzlichen parameter für den fehlercode reinmachen und dann willste schneller sein?
(ach, warum geb ich mis2com eigentlich tips? ich stelle es ein.)
-
ok, dann nehm ich exceptions
-
ich brauche mal ne idee wie ich das vernünftig vergleichen kann, das ist ein fight gegen den compilier und seine fähigkeiten sachen zu optimieren
was haltet ihr von diesen code für den anfang?
#include <iostream> #include <vector> #include <cstdlib> #include <stop_watch.h> using namespace std; vector<int> v( 10 ); int index = 0; void foo() { if(!(index % 100)) throw 1; } int foo_no_excp() { if(!(index % 100)) return 1; return 0; } int main() { #define TEST_EXCP 1 dim::time_measure tm( 100000 ); do { #if TEST_EXCP try { foo(); } catch(int) { v[index++ % 10]++; } #else if(foo_no_excp()) v[index++ % 10]++; #endif }while( tm ); cout << tm << endl;; copy( v.begin(), v.end(), std::ostream_iterator<int>( cout, " * ") ); cout << endl; return 0; }hier ist der inhalt von stop_watch.h, hoffe nicht das es die ergebnise verfälscht
#ifndef STOPWATCH_H_DIM #define STOPWATCH_H_DIM #include <iostream> #include <string> #include <windows.h> namespace dim { typedef __int64 int64_t; class stop_watch { public: stop_watch() { reset(); } void reset() { Sleep( 0 ); starttime_ = ticks(); } int64_t time() const { return ticks() - starttime_; } private: int64_t ticks() const { #pragma warning(disable:4035) __asm rdtsc; #pragma warning(default:4035) } private: int64_t starttime_; }; class average { public: average(unsigned int n) : sum_( 0 ), count_( 0 ), n_( n ) { } bool need_more_values() const { return n_ != 0; } average & operator+= (stop_watch & sw) { sum_ += sw.time(); ++count_; if(n_) --n_; return *this; } int64_t value() const { if(count_) return sum_ / count_; else return sum_; } private: int64_t sum_; unsigned int count_; unsigned int n_; }; class time_measure { public: time_measure(int n) : av_( n ) { } operator void *() { av_ += sw_; sw_.reset(); if(av_.need_more_values() == 0) return NULL; else return (void*)1; } int64_t value() const { return av_.value(); } private: average av_; stop_watch sw_; }; std::string i64tostr(int64_t nr) { std::string res; do { res.insert( res.begin(), nr % 10 + '0' ); nr /= 10; }while(nr); return res; } std::ostream & operator<< (std::ostream & os, const time_measure & sw) { return os << i64tostr( sw.value() ); } std::ostream & operator<< (std::ostream & os, const stop_watch & sw) { return os << i64tostr( sw.time() ); } std::ostream & operator<< (std::ostream & os, const average & av) { return os << i64tostr( av.value() ); } }//end of namespace dim #endif
-
meine benchmarks stinken nach benchmark
hatt jemand code mit viel fehlerhändling usw. das sich für ein benchmark eignet (keine user abfragen usw.)
[ Dieser Beitrag wurde am 03.05.2003 um 01:28 Uhr von Dimah editiert. ]
-
Original erstellt von Dimah:
meine benchmarks stinken nach benchmarkjo.
laß exceptions nicht fliegen, um ein dateiende anzuzeigen, oder nen stack, der leer war. eher, um ne nicht existierende datei oder speichermangel anzuzeigen. und siehe da, die fliegt so sauselten, daß du keine guten chancen hast, die auszumessen.
teste also mal lieberint f(){int r=rand();if(r==0) throw 1;return r;}//nebst catch
gegen
int f(int* err){int r=rand();if(r==0) *err=1;return r;}//nebst if