Codeoptimierung lieber abschalten

[dummzeuch]

Zitat von Andreas13:

Zitat von Benmik:

Delphi-Quellcode:

{$IFDEF DEBUG}
  {$OPTIMIZATION OFF}
{$ENDIF}

Ist das nicht zu riskant? Wir unterdrücken damit eventuelle Fehler im Debug-Modus, lassen sie jedoch in der endgültigen Release-Version zu...

Aber wir haben doch gerade von allen Seiten gehört, dass der Compiler beim Optimieren keine Fehler macht. Selbst mein Hinweis, dass ich solche Fehler schon mehrfach gesehen habe, wurde abgebügelt mit "das Problem war bestimmt in Deinem Code" (nicht dass das falsch wäre, schließlich war es mein Code, der optimiert wurde, ohne ihn wäre kein Fehler aufgetreten, aber es ist nicht hilfreich).

OK, ernsthaft: Das mache ich auch so, allerdings nicht durch ifdef im Sourcecode sondern durch Setzen der Option in der Release-Config. Das ifdef hat den Nachteil, dass es nicht so simpel ist, die Optimierung einzuschalten, weil man dafür den Sourcecode ändern muss.

[Uwe Raabe]

Zitat von dummzeuch:

Das ifdef hat den Nachteil, dass es nicht so simpel ist, die Optimierung einzuschalten, weil man dafür den Sourcecode ändern muss.

Der gravierendste Nachteil ist aber wohl, dass es in jeder Unit stehen muss.

[jaenicke]

Zitat von dummzeuch:

Selbst mein Hinweis, dass ich solche Fehler schon mehrfach gesehen habe

Ich habe dazu lediglich geschrieben, wie meine Erfahrungen mit solchen Meldungen waren. Das heißt nicht, dass das bei dir kein Compilerfehler war.

Konkrete Beispiele fände ich aber interessant.

[Uwe Raabe]

Zitat von jaenicke:

Konkrete Beispiele fände ich aber interessant.

Da kann ich mich nur anschließen! Zum einen kann man testen, ob es im aktuellen Delphi noch vorhanden ist, und zum anderen einen Bugreport schreiben, damit es behoben werden kann.

[Sherlock]

Also ich kann nur sagen, ich benutze die Optimierung immer und bin bisher noch nicht damit gegen eine Wand gefahren. Aber natürlich gibt es immer und überall Fehler, darum testet man ja - sowohl automatisiert als auch mit Menschen.

Hier mal ein paar Beispiele wie Fehler zu handhaben sind:
https://quality.embarcadero.com/browse/RSP-16456
https://quality.embarcadero.com/browse/RSP-34668
https://quality.embarcadero.com/browse/RSP-13831


Sherlock

[dummzeuch]

Zitat von jaenicke:

Konkrete Beispiele fände ich aber interessant.

Hm, ich habe gerade mal den Sourcecode unserer internen Bibliothek nach {$OPTIMIZATION OFF} ge-grep-t. Das einzige Beispiel, das ich dort gefunden habe ist etwas zu komplex, um es hier sinnvoll posten zu können:

Delphi-Quellcode:

finally
// Wenn Optimization on ist, gibt es in Delphi 2007 eine AccessViolation in TLaserData.Done bei
// der Freigabe von FReader. Ohne passiert das nicht.
// -- 2021-04-16 twm
{$OPTIMIZATION OFF}
    for LaserNo := Low(LaserData) to High(LaserData) do
      LaserData[LaserNo].Done;
    FreeAndNil(TrigStream);
    FreeAndNil(OutStream);
  end;
  Result := FRes;
end;
{$IFDEF OPTIMIZATION_IS_ON}
// Ab hier kann man Optimization wieder einschalten. Frueher - also z.B. direkt nach der
// for-schleife ging es nicht.
// -- 2021-04-16 twm
{$OPTIMIZATION ON}
{$ENDIF}

procedure TLaserData.Done;
begin
  FreeAndNil(FReader);
end;

Das sagt ziemlich wenig, ohne den Rest der Methode, aber selbst wenn ich die hier poste könnte, wäre sie ohne Kontext nur sehr schwer verständlich. Laserdata ist ein Array of TLaserData-Records, die optional initialisiert werden, wenn es die entsprechenden Dateien gibt. FReader wurde vor dem zugehörigen try mit NIL initializiert.

Andere Beispiele (ich meine es waren noch zwei weitere), finde ich nicht, die müssen im Source von einzelnen internen Tools gewesen sein, und davon haben wir zuviele um den mal eben zu grep-en.

Obiges Beispiel kann ich noch nicht auf Delphi 10.2 portieren, da es immernoch einen Rechner mit Windows XP gibt, auf dem es laufen muss, deshalb weiß ich nicht, ob der Fehler dort noch auftreten würde.