Try Except Problem

[jaenicke]

Naja, eher sollte diese Einstellung vor Code, die sich auf die eine oder andere Richtung darauf verlässt, grundsätzlich gesetzt werden.

[Dejan Vu]

Ich würde mich bei Delphi gar nicht darauf verlassen. Sonst kommt irgendein Waldschrat mal auf die Idee, das anzuschalten und dann wundert man sich doch etwas.

Ich habe mich bei Delphi jedenfalls nie darauf verlassen.

[himitsu]

Ich hab es aufgegeben alle "Standards" selber nochmal zu setzen.

Wenn irgendein Idiot daran rumspielt, dann hat er Pech und muß mit den Konsequenzen leben.
Ich bin auch dafür, daß solche Optionen endlich mal aus den Projektoptionen raus fliegen oder es zumindestens mit mindestens 200 "Willst du das wirklich?"-Dialogen bestätigen muß.

[Bernhard Geyer]

Zitat von himitsu:

Ich hab es aufgegeben alle "Standards" selber nochmal zu setzen.

Wir bringen bei unseren Projekten einfach einen Compilerfehler wenn die (uralten) Compilerschalter falsch gesetzt sind.

[himitsu]

Jupp, das hab ich bei einigen Codes auch schon gemacht.

Leider gibt es IfOpt nur für die alten einbuchstabigen "+/-"-Optionen.


Einfach so umschalten und danach "zurückschalten" ist einfach nur falsch, vorallem wenn man sich vorher nicht den aktuellen Zustand merkt und danach "wirklich" wiederherstellt.
Leider fehlt auch noch eine Push/Pop-, bzw. Save/Restore-Möglichkeit, für die Compilerschalter.

Sowas wäre ja toll,

Delphi-Quellcode:

{$PUSH Options}  // oder {$PUSH Option X}
{$X+}
machwas;
{$POP Options}

bzw.

Delphi-Quellcode:

{$SAVEOPT X}
{$X+}
machwas;
{$RESTOREOPT X}

aber die Realität sähe etwa so aus

Delphi-Quellcode:

{$IFOPT X+} {$DEFINE _SaveX} {$ELSE} {$UNDEF _SaveX} {$ENDIF}
{$X+}
machwas;
{$IFNDEF _SaveX} {$X-} {$ENDIF}

denn

Delphi-Quellcode:

{$X+}
machwas;
{$X-}

wäre halt sowas von total falsch, wenn das X vorher schon aktiviert war und es danach nicht mehr ist.

[BUG]

Zitat von himitsu:

aber die Realität sähe etwa so aus
[DELPHI]{$IFOPT X+} {$DEFINE _SaveX} {$ELSE} {$UNDEF _SaveX} {$ENDIF}

Oder eben:

Delphi-Quellcode:

{$I StoreOptions}
{$X+}
// Zeug
{$I LoadOptions}

Die Includes müsste man nur einmal schreiben
Aber stimmt schon, ein richtiger eingebauter Optionsstack wäre natürlich besser.

[JamesTKirk]

Zitat von himitsu:

Einfach so umschalten und danach "zurückschalten" ist einfach nur falsch, vorallem wenn man sich vorher nicht den aktuellen Zustand merkt und danach "wirklich" wiederherstellt.
Leider fehlt auch noch eine Push/Pop-, bzw. Save/Restore-Möglichkeit, für die Compilerschalter.

Dann ist ja gut, dass bei diesem Thread Free Pascal drüber steht. Da geht das nämlich:

Delphi-Quellcode:

{$PUSH}
{$X+}
machwas;
{$POP}

Gruß,
Sven

[jaenicke]

Zitat von himitsu:

Wenn irgendein Idiot daran rumspielt, dann hat er Pech und muß mit den Konsequenzen leben.
Ich bin auch dafür, daß solche Optionen endlich mal aus den Projektoptionen raus fliegen oder es zumindestens mit mindestens 200 "Willst du das wirklich?"-Dialogen bestätigen muß.

Ich habe mittlerweile einige Projekte gesehen, bei denen das absichtlich als Standard gesetzt war.
Aber welche anderen Einstellungen bringen denn die Logik potentiell so durcheinander, dass es tragisch wäre, wenn die anders gesetzt sind als erwartet? Da fallen mir ehrlich gesagt auf Anhieb keine ein.

[Dejan Vu]

Zitat von jaenicke:

Aber welche anderen Einstellungen bringen denn die Logik potentiell so durcheinander, dass es tragisch wäre, wenn die anders gesetzt sind als erwartet? Da fallen mir ehrlich gesagt auf Anhieb keine ein.

Wenn Du vollständige Bool'sche Evaluation meinst:
if CalculateFunctionWithSideEffec1 or CalculateFunctionWithSideEffec2 then Klar, wer ist so dämlich... aber es ging ja nur ums einfallen.

[jaenicke]

Zitat von Dejan Vu:

Wenn Du vollständige Bool'sche Evaluation meinst:

Nein, ich meinte andere Einstellungen als eben die vollständige boolsche Auswertung. Klar, wenn man z.B. RTTI Informationen ausklammert, gibt es auch potentiell Fehler, aber das ändert erst einmal nichts an der Programmlogik.