array[1..10] auf Wert prüfen?

[MicMic]

Hallo,
ich habe beispielsweise ein "array[1..10] of boolean".
Kann man die ggf. komplett auf den Wert "True" prüfen? Könnte mir vorstellen, dass dies geht.

Ich mache es halt gerade so (als Beispiel):

Code:

 var w : array[1..10] of boolean;
 ...
 if (w[1] = true) and (w[2] = true) and ... then alles_ist_auf_true();

Bestimmt ist Delphi so klug, dass dies auch einfacher geht :)

Michael

[zeras]

Auf true solltest du nie abtesten, einfach

Delphi-Quellcode:

if w[1] and w[2] usw.

Vielleicht hilft auch eine Schleife weiter, wenn du einmal die Anzahl der zu prüfenden Objekte änderst.

[hoika]

Hallo,

Delphi-Quellcode:

b:= True;
for i:= Low(w) to High(w) do
begin
  if not w[i] then
  begin
    b:= False;
    break;
  end;
end;

[Jumpy]

Oder noch eine Variante

Delphi-Quellcode:

b:= True;
for i:= Low(w) to High(w) do
  b := b and w[i];

[Ydobon]

Oder so vielleicht?

Delphi-Quellcode:

var testFeld, jajajaFeld: Array[1..10] of Boolean;
begin
  ...
  FillChar(jajajaFeld, 10, true);
  if CompareMem(@jajajaFeld, @testFeld, 10) then ShowMessage('Ups');

[freimatz]

Sehr gut:thumb: Das kann super als schlechtes Beispiel dienen. :oops:

[Neutral General]

Zitat:

Zitat von freimatz (Beitrag 1410338)

Sehr gut:thumb: Das kann super als schlechtes Beispiel dienen. :oops:

Begründung?

[freimatz]

Es verletzt mehrere Clean-Code Regeln (KISS, "Vorsicht vor Optimierungen!", POLS), ist nicht evolvierbar und fehleranfällig.
Die Varianten von hoika und Jumpy haben diese Probleme nicht.

[MicMic]

Danke für die Tipps.
Ich dachte ja, es gibt sowas wie "if w[1..10] = true" oder statt ".." vielleicht "-" oder "/". Aber so eine For-Schleife (3 Zeiler von @Jumpy) ist ja auch recht klein. Danke an alle.

@zeras
Aber wieso sollte man nicht auf "true" prüfen (if variable=true then), sprich eher nur "if variable then" nehmen?

Michael

[KodeZwerg]

Nimm lieber eine auf False Prüfen Variante wie diese hier, damit wird es nie zu Problemen kommen.

Zitat:

Zitat von hoika (Beitrag 1410264)

Delphi-Quellcode:

b:= True;
for i:= Low(w) to High(w) do
begin
  if not w[i] then
  begin
    b:= False;
    break;
  end;
end;

False kann/sollte immer nur 0 ergeben, True kann vieles sein.


edit
also auf code Ebene runtergeschraubt

Delphi-Quellcode:

  if not w[i] then
//
  if w[i] = 0 then
..
  if w[i] then
//
  if w[i] > 0 then

Beim kompilieren hat Delphi Wert 1 für True, aber nicht alle Trues sind 1, verstehst Du was ich damit sagen will?

[DeddyH]

Die Konstante true ist mit 1 belegt, tatsächlich ist aber alles <> 0 true. Windows-API-Funktionen geben z.B. gern einmal eine negierte 0 zurück, welcher Wert das dann ist, hängt von der Bitbreite ab. Auf jeden Fall schlägt der Vergleich mit 1 dann fehl.

[Delphi.Narium]

Ich frag' mich immer, warum sollte ich

Delphi-Quellcode:

if variabel = true then

schreiben. wenn doch

Delphi-Quellcode:

if varibel then

vollkommend ausreichend ist? Wahrer als wahr wird es nicht.

Oder:

Warum sollte ich

Delphi-Quellcode:

if variabel = false then

schreiben, wenn doch

Delphi-Quellcode:

if not variabel then

ausreicht? Falscher als falsch wird es nicht.

Von mir aus kann man auch noch

Delphi-Quellcode:

case variabel of
  false : Irgendwas;
else
  was anderes;
end;

machen.

Aber, wenn man bei

Delphi-Quellcode:

case variabel of
  false : irgendwas;
  true  : Nochwas;
else
  UppsWas;
end;

in den Else-Zweig kommt, dann ist der Fall eingetreten, vor dem hier ausdrücklich gewarnt wird.

Und wer mal mit Datenbanken arbeitet und .AsBoolean benutzt weiß, dass das nicht immer funktioniert, dort gibt es nämlich den dritten von zwei möglichen Fällen, nennt sich Null.

[p80286]

Zitat:

Zitat von Delphi.Narium (Beitrag 1410386)

Und wer mal mit Datenbanken arbeitet und .AsBoolean benutzt weiß, dass das nicht immer funktioniert, dort gibt es nämlich den dritten von zwei möglichen Fällen, nennt sich Null.

:mrgreen: :thumb:

Ich habe den Eindruck, das diese "irgendeinbool=true-Diskussion" immer öfter hochkocht.
Das erinnert mich an "sinnvoll" und "das macht Sinn". Nur weil ein Konstrukt in der einen Sprache vorkommt, ist es in der anderen Sprache nicht sinnvoll.


Gruß
K-H

[Delphi.Narium]

Wenn ich höre: Das macht Sinn oder Was für einen Sinn macht es frag' ich mich immer: Was ist das für ein ominöses Es, das nichts weiter tut, als Sinn herstellen. Und vor allem, wie wird Sinn gemacht? Und wie kann Es immer und jederzeit überall sein, um dieser Tätigkeit nachzugehen, ohne dass mir je jemand erklären konnte, wie eigentlich "Sinnmachen" geht. Hat Es auf das "Sinnmachen" ein Patent und wenn ja, wie viel verdient dieses Es dann mit der Vermarktung davon?

Auch wenn man das Englische wörtlich ins Deutsche übersetzen kann, so ist es nicht zwingend sinnvoll oder sinnbringend oder in Falschdeutsch: Das macht keinen Sinn. Man könnte auch einfach sagen: "Sinnmachen" ist unsinnig, "keinen Sinn machen" ebenso.

Genausowenig wie

Delphi-Quellcode:

if varibabel = true then

.

Frage ja auch nicht ab:

Delphi-Quellcode:

if (variabel = 1) and (1 = 1) then

oder gar

Delphi-Quellcode:

if (variabel = 0) and (1 = 0) then

;-)

[freimatz]

Aus technischer Sicht ist ein Vergleich mit True überflüssig. Für mich macht es allenfalls noch Sinn wenn man etwas damit ausdrücken möchte und so den Code lesbarer machten will.

Wenn True und False eher gleichberechtigt sind würde ich vielleicht ein Vergleich auf True in Betracht ziehen wie z.B.:

Delphi-Quellcode:

if UntersuchungsErgebnis = True then

Wenn True eher eine Richtigkeit oder Vollständigkeit anzeigt lasse ich das auf jeden Fall weg wie z.B. bei

Delphi-Quellcode:

if UntersuchungsAbgeschlossen then

In den meisten Fällen die obigen ersten Fall entsprechen würde ich aber eher einen eigenen Aufzählungstyp definieren wie z.B.

Delphi-Quellcode:

TUntersuchungsErgebnis = (positiv, negativ);

Dann wird gleich auch der Typ immer vom Compiler geprüft.

Obige Unterscheidung kommt bei mir ähnlich häufig bei unit tests vor. So schreibe ich z.B.:

Delphi-Quellcode:

CheckTrue( Assigned(parameter) )

andererseits

Delphi-Quellcode:

CheckEquals(True, Testklasse.UntersuchungsErgebnis);

oder

Delphi-Quellcode:

CheckEquals(False, Testklasse.UntersuchungsErgebnis);

[Dennis07]

Um nochmal auf das Problem zurückzukommen, ich würde es sogar mit einer

Delphi-Quellcode:

for in

-Schleife machen, da man hier ja nur lesezugriff braucht. Wäre noch etwas schneller und einfacher:

Delphi-Quellcode:

function AssertArray(AArray: TArray<Boolean>): Boolean;
begin
  for Result in AArray do
  begin
    if not Result then
    begin
      Exit;
    end;
  end;
end;

Das wäre sicherlich die Eleganteste Lösung.

[himitsu]

Auf was Result wohl steht, wenn das Array leer ist? :roll:

Und per Definition sind Array-Variablen außerhalb der Schleife ungültig/undefiniert, unabhänbgig davon ob das manchmal/oftmals nicht so ist.

[Dennis07]

Zitat:

Zitat von himitsu (Beitrag 1410406)

Auf was Result wohl steht, wenn das Array leer ist? :roll:

Dann ist der Rückgabewert undefiniert. Was Allerdings ja nicht sein kann, da das Array ja bei ihm angeblich immer 10 hat. Aber selbst wenn nicht, was soll denn in so einem Fall korrekterweise widergegeben werden?

Delphi-Quellcode:

True

, weil es kein

Delphi-Quellcode:

False

gibt oder

Delphi-Quellcode:

False

, weil es kein

Delphi-Quellcode:

True

gibt? Wenn du das entschieden hast, kannst du ja dann noch eine Initializierung unten vornehmen. Oder, wohl noch besser, vorher auf

Delphi-Quellcode:

Length(AArray <> 0)

prüfen und ansonsten eine Fehlermeldung ausgeben.

Zitat:

Zitat von himitsu (Beitrag 1410406)

Und per Definition sind Array-Variablen außerhalb der Schleife ungültig/undefiniert, unabhänbgig davon ob das manchmal/oftmals nicht so ist.

Nö, außerhalb der Schleife sind es normale lokale Variablen. Bei

Delphi-Quellcode:

for

kann es allerdings passieren, dass sie nicht initialisiert wurden. Das passiert immer genau dann, wenn sie nicht ein einziges mal durchlaufen wurde. Ansonsten hält sie immer den Wert des letzten Durchlaufs (check after loop).

[himitsu]

Der Witz ist, dass der Compiler die Zählvariable optimieren kann und aus eimen

Delphi-Quellcode:

for i := 1 to 11 do

intern schonmal zu einem

Delphi-Quellcode:

for i := 10 downto 0 do

wird.
Innerhalb der Schleife würde das beim Zugriff auf diese Variable wieder umgegreht, falls diese Variable überhaupt ausgelesen wird, aber nach der Schleife bleibt i eventuell bei 0 oder sogar -1 stehen, was man versteht, da das INC/DEC vor der Abbruchbedingung liegen könnte und der Vergleich mit 0 kürzeren optimaleren Prozessor-Code erzeugt.

[Dennis07]

Zitat:

Zitat von himitsu (Beitrag 1410446)

Der Witz ist, dass der Compiler die Zählvariable optimieren kann und aus eimen

Delphi-Quellcode:

for i := 1 to 11 do

intern schonmal zu einem

Delphi-Quellcode:

for i := 10 downto 0 do

wird.
Innerhalb der Schleife würde das beim Zugriff auf diese Variable wieder umgegreht, falls diese Variable überhaupt ausgelesen wird, aber nach der Schleife bleibt i eventuell bei 0 oder sogar -1 stehen, was man versteht, da das INC/DEC vor der Abbruchbedingung liegen könnte und der Vergleich mit 0 kürzeren optimaleren Prozessor-Code erzeugt.

Was zwar sein kann (ist mir zwar noch nicht unter gekommen, aber das Gerücht habe ich auch schonmal gehört), allerdings ist es für

Delphi-Quellcode:

for in

-Schleifen ja eh völlig egal, in welcher Reihfolge diese ausgeführt werden. Du kannst ja mal meinen Code durchgehen unter der Prämisse, dass eine

Delphi-Quellcode:

for in

-Schleife immer Rückwärts ausgeführt werden würde, und wirst feststellen, dass es am Ergebnis und der Funktionalität der Routine absolut gar nichts ändert.

[Dennis07]

Aber wenn es dich so krass stört, die Ergebnisvariable als Schleifenvariable zu verwenden, dann bitte...

Delphi-Quellcode:

function AssertArray(AArray: TArray<Boolean>): Boolean;
var
  Current: Boolean;
begin
  for Current in AArray do
  begin
    if not Current then
    begin
      Exit(False);
    end;
  end;
  Result := True;
end;

[hoika]

Hallo,

Zitat:

Innerhalb der Schleife würde das beim Zugriff auf diese Variable wieder umgegreht, falls diese Variable überhaupt ausgelesen wird, aber nach der Schleife bleibt i eventuell bei 0 oder sogar -1 stehen, was man versteht, da das INC/DEC vor der Abbruchbedingung liegen könnte und der Vergleich mit 0 kürzeren optimaleren Prozessor-Code erzeugt.

Das ist nicht ganz korrekt.
Wenn die Schleifenvariable innerhalb der Schleife nicht benutzt wird, optimiert das der Compiler,
weil ein Compare mit 0 als Endergebnis der Schleifenvariable schneller ist.

Wird die Schleifenvariable innerhalb der Schleife benutzt, zählt der "Compiler richtig".

Und eine Schleifenvariable darf eh nicht außerhalb der Schleife benutzt werden.
Das bringt auch hoffentlich eine Compilerwarnung, wenn es trotzdem versucht wird.

[p80286]

Zitat:

Zitat von hoika (Beitrag 1410471)

Und eine Schleifenvariable darf eh nicht außerhalb der Schleife benutzt werden.
Das bringt auch hoffentlich eine Compilerwarnung, wenn es trotzdem versucht wird.

Unglücklich formuliert:

Delphi-Quellcode:

var i : integer;
  text:string;
begin
  text:='';
  for i:=1 to 7 do
    text:=text+'m';
  for i:=1 to 5 do
    text:=text+'n';
  //showmessage(text+inttostr(i));

das funktoniert ohne Warnung

während das

Delphi-Quellcode:

var i : integer;
  text:string;
begin
  text:='';
  for i:=1 to 7 do
    text:=text+'m';
  for i:=1 to 5 do
    text:=text+'n';
  showmessage(text+inttostr(i));

eine Warnung nach sich zieht.

[Warnung] Unit1.pas(35): FOR-Schleifenvariable 'i' kann nach Durchlauf undefiniert sein

Also eher "der Zugriff auf die Schleifenvariable ohne erneut einen Wert zugewiesen zu haben"

Gruß
K-H

[hoika]

Hallo,
warum sollte Dein erstes Code-Stück eine Warnung erzeugen?

Zitat:

Also eher "der Zugriff auf die Schleifenvariable ohne erneut einen Wert zugewiesen zu haben"

Jein, die Schleifenvariable steht meistens in einem Register (ax,eax usw.).
Dieser Registerinhalt kann nach "einer Weile" Code hinter der Schleife einfach einen anderen Wert haben.

[Dennis07]

Zitat:

Zitat von hoika (Beitrag 1410471)

Und eine Schleifenvariable darf eh nicht außerhalb der Schleife benutzt werden.
Das bringt auch hoffentlich eine Compilerwarnung, wenn es trotzdem versucht wird.

Das ist nicht ganz richtig. Es wird keine Wahrnung deshalb ausgegeben, weil es eine Schleifenvariable ist, sondern nur deshalb, weil sie bei einer

Delphi-Quellcode:

for

-Schleife möglicherweise undefiniert sein könnte (nämlich ist sie das genau immer dann, wenn die Schleife kein einziges mal durchlaufen wurde). Die selbe Wahrnung wird dir aber auch ausgegeben, wenn du auf eine andere Variable zum Lesen zugreifst, die vorher möglicherweise nicht initialisiert wurde. Deshalb kommt es immer auf den Einzelfall an, und nur weil eine Wahrnung ausgegeben wurde, heißt es noch lange nicht, dass das gesagte auch stimmen muss. Der Compiler durchblickt deinen Quellcode eben nur bis zu einem gewissen Punkt.

Zitat:

Zitat von hoika (Beitrag 1410519)

Jein, die Schleifenvariable steht meistens in einem Register (ax,eax usw.).

Für gewöhnlich eher in ECX (Das "C" steht nämlich für "counter").
Wobei das durchaus schonmal variieren kann, je nach dem, wie die Routine sonst noch so aussieht. Das EAX-Register würde aber ohnehin nicht viel Sinn ergeben, da dort ja das Ergebnis der Funktion in der Regel drin steht.

[Dennis07]

Zitat:

Zitat von hoika (Beitrag 1410519)

Dieser Registerinhalt kann nach "einer Weile" Code hinter der Schleife einfach einen anderen Wert haben.

Und nein, das stimmt einfach nicht. Sorry, aber das ist falsch.
Die Zählervariable ist eine ganz normale Variable, die vor oder auch danach einen festen Wert hat/haben kann.
Deshalb kannst du ja auch 2

Delphi-Quellcode:

for

-Schleifen hintereinander packen ohne dass es zu Problemen kommt.

Delphi-Quellcode:

program CountTo100;

var
  I: Integer;
begin
  for I := 1 to 50 do WriteLn(I);
  WriteLn('Halbzeit');
  for I := Succ(I) to 100 do WriteLn(I);
  WriteLn('Fertig');
end.

Das funktioniert so einwandfrei, und da wird nichts "umgepackt". Der Compiler managet deine Variablen schon alle, und das ohne dir da irgendwas zu überschreiben. Und schon überhaupt nicht überschreibt der dir die Ergebnisvariable irgendwo im Code, ohne, dass du das willst. Wenn es mehr Variablen/Parameter als Register gibt, dann werden Sachen auf dem Stack abgelegt.

[himitsu]

Code:

...
50
Halbzeit
52
...

sieht nicht ganz richtig aus.

[bernau]

Zitat:

Zitat von Dennis07 (Beitrag 1410537)

Delphi-Quellcode:

program CountTo100;

var
  I: Integer;
begin
  for I := 1 to 50 do WriteLn(I);
  WriteLn('Halbzeit');
  for I := Succ(I) to 100 do WriteLn(I);
  WriteLn('Fertig');
end.

Ab

Delphi-Quellcode:

WriteLn('Halbzeit')

hat I keinen definierten Zustand. D.h.

Delphi-Quellcode:

Succ(I)

produziert in der zweiten Schleife einen zufälligen Wert. Kann sein, dass es jetzt für dich (zufällig) funktioniert. Würde ich mich aber nicht drauf verlassen.

[himitsu]

Was ich ja bereits gesagt hatte:
Außerhalb der Schleife ist die Schleifenvariable undefiniert, also es wird nicht "garantiert", dass sie dort einen bestimmten wert hat.

Dass sie es doch mal haben kann, ist eine andere Sache, auf die man sich aber niemals verlassen kann.
Die Variable kann/darf man außerhalb auch gern wiederverwenden, für eine andere Schleife oder für sonstwas, aber dort hat man sie natürlich vorer zu initialisieren.

Eigentlich wäre es konsequent, wenn der Compiler hier seinen "Variable wurde initialisiert"-Status nach der Schleife zurücksetzt.
Aber es ist hier das gleiche Problem wie mit nichtinitialisierten Funktions-Results, welche ebenfalls nicht "bemängelt" werden, wenn es sich um einen gemanagten Typen ala String handelt, da er ja per se initilisiert ist (außerhalb der Funktion), aber ihr dennoch keinen "definierten" Initialwert besitzt.


Für Schleifen in C++ ist das was anderes, denn dort "definierst" DU was wie mit der Variable passiert.

Code:

for (i = 0; i < 10; i++)

[Dennis07]

Zitat:

Zitat von himitsu (Beitrag 1410538)

Code:

...
50
Halbzeit
52
...

sieht nicht ganz richtig aus.

Jo, hast recht. Hatte es nur unter FPC eben im Browser getestet, und da zählt der bei 51 weiter. Unter Delphi bei 52. Ist ja auch egal, FPC interessiert mich sowieso nicht wirklich. In Delphi und SMS bekomm muss ich nur das

Delphi-Quellcode:

Succ

weg lassen, und bekomme 51.

Zitat:

Zitat von bernau (Beitrag 1410567)

Ab

Delphi-Quellcode:

WriteLn('Halbzeit')

hat I keinen definierten Zustand. D.h.

Delphi-Quellcode:

Succ(I)

produziert in der zweiten Schleife einen zufälligen Wert. Kann sein, dass es jetzt für dich (zufällig) funktioniert. Würde ich mich aber nicht drauf verlassen.

Das stimmt doch nicht. Der Wert, den

Delphi-Quellcode:

Succ(I)

zurückgibt, ist immer der selbe. Ich habe es jetzt spaßeshalber mal mit 5 verschiedenen Konstellationen einige Male durchgespielt, und die Schleifenvariable war in keinem einzigen Fall undefiniert, so lange die Schleife mindestens 1 mal durchlaufen wurde. Warum sollte sie das auch sein, es wurde ja im späteren Verlauf nichts reingeschrieben.

Bitte, und das geht jetzt auch an alle anderen, die meinen, dass das nur "eine glückliche Ausnahme" sei: Schickt mir mal einen einzigen Code-Schnipsel, in dem das nicht der Fall ist, und ich nehme alles wieder zurück und gebe zu, dass ich falsch lag. Aber bisher habe ich noch nichts dergleichen bemerkt.

Delphi-Quellcode:

for

-Schleifen, die durchlaufen, behalten ihren Wert hinterher.

Ich habe anbei mal den ASM-Code für eine Leere For-Schleife von 1 bis 5 mit angehängt. Da sieht man ziemlich gut, wie eine For-Schleife funktioniert, und auch, dass immer nach oben gezählt wird.

[bernau]

Schau mal hier

Dort ist extra angegeben, dass die Variable nach Schleifendurchlauf undefiniert ist.

Durch Codeoptimierung des Compilers "könnte" die Variable nicht den erwarteten Wert haben. Nur weil du jetzt keinen Codeschnipsel bekommst, der das zeigen kann, bedeutet es nicht, dass es nicht doch passieren kann.

Außerdem kann mit einer neuen Compilerversion das Verhalten des bestehenden "funktionierenden" Codes verändert werden. Siehst du schon, dass FPC und Delphi den Code unterschiedlich ausführen.

Ich wäre da sehr vorsichtig.

[KodeZwerg]

Zitat:

Zitat von bernau (Beitrag 1410689)

Dort ist extra angegeben, dass die Variable nach Schleifendurchlauf undefiniert ist.

Nee.

Zitat:

FOR-Loop variable '%s' may be undefined after loop

may = könnte.
Lustig das Du sowas für meine Delphi Version gefunden hast.

[bernau]

Zitat:

Zitat von KodeZwerg (Beitrag 1410693)

Nee.

Zitat:

FOR-Loop variable '%s' may be undefined after loop

may = könnte.

Das reicht doch schon um eine Variable als undefiniert anzusehen. Außer ich weiß, wann die Variable undefiniert sein könnte.

:roll:

[KodeZwerg]

Das "may/könnte" gibt eher an das es am Programmierer liegt dafür Sorge zu tragen ob etwas un-/definiert ist.

[Schokohase]

Zitat:

Zitat von KodeZwerg (Beitrag 1410710)

Das "may/könnte" gibt eher an das es am Programmierer liegt dafür Sorge zu tragen ob etwas un-/definiert ist.

Das „may“ gibt an, dass bei der Entwicklung des Compilers kein Wert darauf gelegt wird, dass in der Schleifenvariable nach der Schleife ein bestimmter Wert enthalten ist auf den man sich verlassen kann.

Wer sich darauf verlässt, ist sozusagen von allen guten Geistern verlassen.

[KodeZwerg]

Schlussendlich, da es ein "may" ist, könnten alle Aussagen zutreffen. Punkt, Ende und abgehakt.

[himitsu]

Egal ob "geht garnicht" oder "geht eventuell nicht",
das Verhalten ist so nicht vorgegeben, also kann/darf man sich nicht auf sowas verlassen.

Außer in Ausnahmefällen, kann darf sowas niemals "immer" in Produktivcode verwendet werden.

[Sherlock]

Zitat:

Zitat von KodeZwerg (Beitrag 1410714)

Schlussendlich, da es ein "may" ist, könnten alle Aussagen zutreffen. Punkt, Ende und abgehakt.

Das mag jetzt hart klingen, vielleicht verletzend, muss aber so gesagt werden:
Ein Entwickler, der einen Fall ignoriert, dessen Auftreten explizit erwähnt wird, sollte den Beruf wechseln.

In diesem Sinne, nix für ungut. Hier haben sich alle Lieb.

Sherlock

[KodeZwerg]

Bestimmt ist es so wie Ihr schreibt und jede Compiler Warnung "Variable X may not be initialized" ist zu 100% definitiv nicht initialisiert.... einfach nur dumm so eine Aussage. Klar sollte man sich Gedanken machen wieso der Compiler mir so etwas erzählt. Aber es bleibt bei einem MAY. Apropo may, mayday mayday, bin raus hier.

Mir ging es nur um Bernaus Übersetzung und nicht irgend welche Code-Schnippsel oder irgend ein anderer Zusammenhang.

[Neutral General]

Hier haben sich in einem Projekt eine ganze Menge Warnungen dieser Art angesammelt und wir sind jetzt dran die ganzen Warnungen etc anzugehen um potenzielle Fehlerquellen auszuschließen.
Habe schon unzählbare Warnungen dieser Art korrigiert und jedes einzelne Mal hatte der Compiler Recht und die Variable WAR nicht initialisiert.

Von daher kann ich dir erfahrungsgemäß sagen, dass zu 99-100% diese Warnung ernst zu nehmen ist und wenn du glaubst der Compiler hat Unrecht dann ist das Problem wahrscheinlich dass der Compiler mehr weiß als du (und Recht hat).
Ich hatte jetzt den Fall dass viele dieser Warnungen aufgrund von "Glück" und "Magie" in einem 32-Bit Programm keinen Ärger machen.
Nachdem ich das Programm dann als 64-Bit exe compiliert habe, haben sich eine ganze Menge dieser Warnungen in ziemlich zuverlässige Laufzeitfehler verwandelt.