![]() |
AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung
Zitat:
|
AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung
Immerhin gibt es
Zitat:
|
AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung
Richtig, das habe ich auch beim c++-Builder gesehen. Ist standardmäßig leider auch nicht an, aber in C++ habe ich dafür noch Verständnis ;-)
Aber man hat die Option. In Delphi sehe ich nichts. Ich bin die letzten 18 Monate wirklich immer davon ausgegangen, dass ich vor so etwas gewarnt werden würde. Mein Weltbild gleicht nun einem Scherbenhaufen. |
AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung
Zitat:
Delphi-Quellcode:
Was vergessen? Bestimmt. Aber das Prinzip ist klar.
if (variable) then...
CallMethod(variable); // Parameter ist kein var/out someOtherVariable := variable; variable := variable + 1; Zum Thema: So eine Warnung könnte der Compiler schon ausgeben und generell bei Konvertierungen zu warnen, wenn Daten verloren gehen könnten, dauert nun auch nicht länger, weil ja die konkrete Art der Konvertierung (Typ-A -> Typ-B) bekannt ist und man in einer einfachen Tabelle gucken könnte: "Meckern" / "Nicht meckern". Ganz klar: Vergessen oder mit Absicht. |
AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung
Dass der Compiler auch nicht warnt, wenn man bestimmte Typen (z.B. Interface) zurückgibt und nie initialisiert hatten wir auch:
![]() Das ist der Grund warum ich mich fanatisch den Tag herbeibeschwöre an dem es endlich den "Nextgen"-Compiler für Windows gibt. Wenn die ganzen Altlasten weg sind kann Embarcadero hoffentlich endlich ein paar Compilerschalter mehr einbauen... |
AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung
Zitat:
Aber im Ernst, der weiter oben angesprochene cast sollte explizit erfolgen, worüber sich dann nur die AltenSäcke aufregen würden. Aber die Zeiten ändern sich halt. Gruß K-H Zitat:
Da es durchaus Programierer gibt, die nicht wissen was sie tun (copy&paste) würde ich sagen: Ja |
AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung
Dann werden doch nur alte Ärgernisse durch neue ersetzt. Obwohl. Abwechslung muss sein.
|
AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung
Zitat:
Mit einem kleinen Problem, welcher aber erst auffällt, wenn man die Interna kennt. (drum wird auch bei einem Integer gewarnt, aber nicht bei einem String)
Delphi-Quellcode:
[DCC Warnung] ...: W1036 Variable 'i' ist möglicherweise nicht initialisiert worden
function Test1: Integer;
var i: Integer; begin if i = 0 then ; end; function Test2: string; var S: string; begin if S = '' then ; end; [DCC Warnung] ...: W1035 Rückgabewert der Funktion 'Test1' könnte undefiniert sein Aber bei den beiden Strings gibt es keine Warnung. Wie gesagt, Strings (mit Ausnahme des ShortString) und andere Typen werden automatisch initialisiert, da sonst die automatische Speicherverwaltung nicht funktionieren würde.
Delphi-Quellcode:
wird vom Compiler intern als
function Test(i: Integer): string;
Delphi-Quellcode:
umgesetzt.
procedure Test(i: Integer; var Result: string);
Hier übernimmt der Aufrufer die Initialisierung, was oftmals nicht auffällt, aber ruf mal diese Funktion in einer Schleife auf. :stupid: |
AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung
Zitat:
Gruß K-H |
AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:57 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz