URL: https://www.overclockers.at/coding-stuff/an_die_c_gurus_86491/page_1 - zur Vollversion wechseln!
An die C++ Gurus hier (wie viele gibt's davon? 1? 2?)
http://www.cuj.com/documents/s=8000...xp1812alexandr/
Sehr praktischer Artikel. Ich verwende das Zeug gerade in einem größeren Projekt in C++Builder , und es ist wirklich sehr angenehm, damit zu arbeiten.
Ich hab die Files ScopeGuard.h und Janitor.h von irgendwo gesaugt, ich finde nur nicht mehr, von wo, und im Artikel sehe ich keinen Link mehr dazu. Also wenn sie wer haben will, kann ich sie gern zuschicken. Vielleicht bin ich aber auch nur blind.
EDIT: Ah, da hab ich's eh wieder gefunden: ftp://ftp.cuj.com/pub/2000/cujdec2000.zip
EDIT2: ScopeGuard allein macht Probleme mit dem Borland Compiler (5.6.4). Er meckert zwar nicht beim Compilieren, aber es funktioniert dann nicht. Die Destructors werden nicht aufgerufen, wenn eine Exception geworfen wird. Daher verwende ich jetzt nur Janitors, die funktionieren einwandfrei.
cool, thx, das werd ich demnächst mal ausprobieren. Vielleicht kann man ja damit endlich Exceptions brauchbar verwenden.
Also ich denke, dass ich es in meinem jetzigen Projekt recht gut geschafft habe. Es fällt mir vor allem sehr positiv auf, dass ich nicht wieder sämtliche Fehler durchreichen muss, wenn ich im Zuge des Refactoring eine weitere Schicht einführe. Wenn alles mal auf Exceptions und automatischer Ressourcenverwaltung aufgebaut ist, muss man sich wirklich nicht mehr drum kümmern.
c++ builder bietet ja afaik, genauso wie der ms compiler, ein try/__finaly - analog zu java - ist halt aber kein ansi standard.
Ich weiß, aber wenn man mehr als eine Sache zu erledigen hat, wird's mühsam, denn dann muss jedes einen eigenen try/__finally Block kriegen, und das ist nicht gerade sehr übersichtlich.
Ideen was man tun könnte, um 500000 Zeilen alten Code (verschiedenste Errorhandling-Strategien, verschiedene DLLs, Win32-Callbacks dazwischen, ...) exception-safe zu machen?
Es so lassen
Exceptions nachträglich einführen ist ziemlich unmöglich, würd ich mal sagen. Man kann sie natürlich in neuen Programmteilen verwenden, aber bevor sie in den alten Code vordringen können, müssen sie schön abgefangen werden.
Sonst kannst du natürlich einen Leak Detector verwenden, der alle vom Programm verwendeten Ressourcen kennt, und dann an jeder nur erdenklichen Stelle Exceptions werfen und schauen, was passiert . Die Win32 Callbacks müssen natürlich noch extra abgesichert werden.
Mir sind Exceptions immer noch suspekt, u.a. auch wegen folgendem:
ZitatWithout being given any additional information, how many execution paths could there be in the following code?Code:String EvaluateSalaryAndReturnName( Employee e ) { if( e.Title() == "CEO" || e.Salary() > 100000 ) { cout << e.First() << " " << e.Last() << " is overpaid" << endl; } return e.First() + " " + e.Last();
Das kann dir aber eigentlich egal sein, darum muss sich der Compiler kümmern. Solange man alles, was aufgeräumt werden muss, mit einem entsprechenden ScopeGuard versieht, läuft alles wunderbar und automagisch
Hab grad noch was von den gleichen Autoren gefunden, was ebenfalls sehr nützlich ausschaut. In der Praxis hab ich's natürlich noch nicht verwendet, weil ich es gerade erst lese, aber ich habe definitiv vor, das zu tun.
http://www.cuj.com/documents/s=8250...xp2106alexandr/
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025