D
Andromeda schrieb:
Nope, wenn das OS hardwaregestützt bereits den Fehler abfängt, brauchst du ihm nur die Adresse der Handler-Routine mitzuteilen. Alles weitere geschieht vollautomatisch.
A-ha. Vollautomatisch, mit Unterstützung des OS. Ohne Laufzeitkosten.
Frage: Woher weiß denn das OS, welcher Handler jetzt aufgerufen werden soll? Jetzt class exception_1, oder doch exception_2? Oder exception_372192? Nicht nur, dass man damit im Voraus angeblich weiß, welche Fehler eine Subroutine auslösen kann - bisher haben wir in den catch-Blöcken halt nur ausgewählte Typen, oder halt alles, wennde lustig bist, da könnte man dann tatsächlich von einem Universal-Handler sprechen - nein, jetzt wissen wir auch auf einmal, welche Exceptions Unterfunktionen, die von der eigentlichen Funktion aufgerufen werden, werfen können.
Dass nicht ausgelößte C-Fehlercodes wie nicht ausgelößte C++-Exceptions den gleichen Laufzeitverlust besitzen (außer vielleicht ein bisschen mehr Code im C++-Handler, aber das kann ein Compiler gut kompensieren, indem er den kritischen Pfad Im Binary möglichst beeinanderhält und den Handler ans Ende der Routine packt), das mag ich noch glauben.
Aber das von dir angegebene Schema würde eine vollständige Linkzeitüberprüfung des Programmes erfordern. Möglich ist das, klar. Aber erst einmal muss für den Linker irgendwie ersichtlich sein, welche Exceptions von welcher Funktion geworfen werden können und in welchen Codepfaden welche Handler für welche Typen erlaubt werden.
Und C++ kompiliert langsam, das wissen wir auch schon seit langer Zeit. Aber das Linken geht meiner Erfahrung nach recht fix. Für das von dir beschriebene Verhalten müsste der Linker meines Erachtens bei einer Linkzeitüberprüfung sehr viel länger rodeln, als er das normalerweise tut. Außerdem ist damit auch noch nicht das Problem gelöst, dass der Handler im Kontext eines bestimmten Stackframes ausgeführt werden muss und bis dahin auch erst einmal zurückgedreht werden muss. Wie will das OS sowas hardwareunterstützt hinbekommen?
