Warnung des Compilers verstehen

[hsg]

Hallo Leute,

ich habe folgende Methode:

Delphi-Quellcode:

function TUser.Rechte(cModul: String) : string;
begin
  if AnsiCompareText(cModul,'Angebot') = 0 then         Result  := FAngebot
  else if AnsiCompareText(cModul,'Auftrag') = 0 then    Result  := FAuftrag
  else if AnsiCompareText(cModul,'AV') = 0 then         Result  := FAV
  else if AnsiCompareText(cModul,'Fertigung') = 0 then  Result  := FFertigung
  else if AnsiCompareText(cModul,'Einkauf') = 0 then    Result  := FEinkauf
  else if AnsiCompareText(cModul,'Versand') = 0 then    Result  := FVersand
  else if AnsiCompareText(cModul,'Reparatur') = 0 then  Result  := FReparatur
  else if AnsiCompareText(cModul,'Supply') = 0 then     Result  := FSupply
  else if AnsiCompareText(cModul,'Kunden') = 0 then     Result  := FKunden
  else if AnsiCompareText(cModul,'Artikel') = 0 then    Result  := FLager
  else if AnsiCompareText(cModul,'Projekt') = 0 then    Result  := FProjekt
  else if AnsiCompareText(cModul,'Zeichnung') = 0 then  Result  := FZeichnung
  else if AnsiCompareText(cModul,'Pruefmtl') = 0 then   Result  := FPruefmtl
  else if AnsiCompareText(cModul,'Iso9000') = 0 then    Result  := FIso9000
  else if AnsiCompareText(cModul,'System') = 0 then     Result  := FSystem
  else if AnsiCompareText(cModul,'Dokument') = 0 then   Result  := FDok
  else                                                  Result  := '';
end;

Beim Übersetzen meldet nun der Compiler "W1035 Rückgabewert der Funktion 'TUser.Rechte' könnte undefiniert sein"
Warum?
Auch ein Initialisieren von Result ändert nichts an der Meldung.

Irgendwelche Ideen?
Gruss Jörg

[Techcrawler]

Sowas meldet der Compiler immer, wenn ein Rückgabewert nicht eindeutig gesetzt werden _könnte_!
Leider erkennt der Compiler nicht, dass in deinem Fall das result immer gesetzt wird (durch das abschließende else).
Am besten, du läßt das else am ende weg und schreibst _vor_ dem if Teil ein
result := '';
dann sollte die Meldung fort sein.

[hsg]

Zitat:

Zitat von Techcrawler

Am besten, du läßt das else am ende weg und schreibst _vor_ dem if Teil ein
result := '';
dann sollte die Meldung fort sein.

Hatte ich probiert (bzw. ist so jetzt eingebaut), die Meldung kommt trotzdem. :?:

[JasonDX]

An sich sollte eine Warnung in dem Fall nicht kommen... Entweder es ist ein Bug, oder der Kompiler meint eine andere Methode namens "Rechte". Hast du diese ueberladen?
Ansonsten koenntest du dich langsam ans Problem herantasten, und bspw. den gesamten Teil auskommentieren, und nur result etwas zuweisen, und dann Schritt fuer Schritt langsam den originalen Code wiederherstellen, bis die Meldung kommt. Damit kannst du den Problempunkt eingrenzen.

greetz
Mike

[rider]

Normalerweise sollte hier keine Warnung kommen. Der Compiler erkennt sehr wohl, dass Result in diesem Fall immer definiert ist.
Aus deinem Code geht leider nicht hervor, wie z.B. TUser und die ganzen FAngebot, FAuftrag, usw. definiert sind.

[hsg]

Zitat:

Zitat von rider

Normalerweise sollte hier keine Warnung kommen. Der Compiler erkennt sehr wohl, dass Result in diesem Fall immer definiert ist.
Aus deinem Code geht leider nicht hervor, wie z.B. TUser und die ganzen FAngebot, FAuftrag, usw. definiert sind.

TUser ist eine selbstgeschriebene Klasse in der Unit (Abgeleitet von TObject), FAngebot, etc. sind Klassenmember vom Typ string

Zitat:

Zitat von JasonDX

Ansonsten koenntest du dich langsam ans Problem herantasten, und bspw. den gesamten Teil auskommentieren, und nur result etwas zuweisen, und dann Schritt fuer Schritt langsam den originalen Code wiederherstellen, bis die Meldung kommt. Damit kannst du den Problempunkt eingrenzen.

Habe ich jetzt mal gemacht: Es scheint an der Anzahl der "if then else" Blöcke zu liegen. Bei 10 Blöcken ist die Welt noch in Ordnung, kommt ein weiterer hinzu kommt die Warnung.
Dabei ist es egal welcher der Blöcke dann hinzukommt oder welche vorher weggelassen wurden.

Gruss Jörg

[uligerhardt]

Zitat:

Zitat von hsg

Habe ich jetzt mal gemacht: Es scheint an der Anzahl der "if then else" Blöcke zu liegen. Bei 10 Blöcken ist die Welt noch in Ordnung, kommt ein weiterer hinzu kommt die Warnung.
Dabei ist es egal welcher der Blöcke dann hinzukommt oder welche vorher weggelassen wurden.

Das hab ich auch grad festgestellt und ich kann's ja irgendwie verstehen, dass der Compiler diese Prüfungen nur bis zu einer gewissen Iterationstiefe (oder so) macht. Wieso er aber meckert, selbst wenn man Result := 'Blah'; als erste Zeile hinzufügt, verstehe ich nicht: Die Initialisierung von Result kann man ja schlecht wieder rückgängig machen. :gruebel:

[rider]

Zitat:

Zitat von hsg

Habe ich jetzt mal gemacht: Es scheint an der Anzahl der "if then else" Blöcke zu liegen. Bei 10 Blöcken ist die Welt noch in Ordnung, kommt ein weiterer hinzu kommt die Warnung.

Dann scheint's wohl doch am Compiler zu liegen - ich hab's nur mit ein paar else Blöcken getestet.
Dann bleibt wohl nichts anderes übrig, als den ganzen Block mit {$WARNINGS OFF} {$WARNINGS ON} zu markieren.

Evtl. würde ich einen Bericht ins Borland Quality Central setzen.
Womöglich hängt es aber mit diesem Bug zusammen:
http://qc.borland.com/wc/qcmain.aspx?d=735

[hsg]

der dortige Fehler ist ja immer noch in Delphi (BDS 2006)
Scheint mir in der Tat der gleiche Fehler zu sein.

Na gut, werde ich wohl die Warnings dort ausschalten.

Danke und Gruss
Jörg

[nieurig]

Hi Leute!
ich löse diese Probleme immer mit

Function foo() : String
VAR Erg:String;
Erg := '';

// dann den ganzen if - Kram
if ...
Erg := ????


// und am Ende EIN result
result := Erg;


Schöne Grüße
Niels

[hsg]

So mache ich es auch an vielen Stellen und hab es in die entsprechende Methode auch eingebaut, die Warning bleibt aber.

[rider]

Auch wenn die falsche Compiler-Warnung ein Bug ist, solche Endlos-If-Ketten mit Stringvergleichen sind mir vom Programmcode ein wenig suspekt.
Schon mal daran gedacht, das Ganze via Enumtyp zu lösen? Dann könnte man ein performantes case-Statement verwenden.

[hsg]

Zitat:

Zitat von rider

Auch wenn die falsche Compiler-Warnung ein Bug ist, solche Endlos-If-Ketten mit Stringvergleichen sind mir vom Programmcode ein wenig suspekt.
Schon mal daran gedacht, das Ganze via Enumtyp zu lösen? Dann könnte man ein performantes case-Statement verwenden.

Der Source stammt aus meinen Anfangstagen in Delphi in einem etwas größerem Projekt.
Wenn ich mal Zeit finde werde ich es umbauen. Ich war nur auf die Stelle gestossen, weil ich versucht habe, dieses Projekt Warnings-frei zu machen.

Im nächsten Leben gelobe ich Besserung :lol:

[hoika]

Hallo,

Notlösung wäre, intern in 2 Methoden aufzusplitten.


Heiko

[Corpsman]

hmm ich komm da nu nich ganz mit.

Ich habe es mal durch meinen Codeformater gejagt und von meinem Compiler Compilieren lassen.

Delphi-Quellcode:

Function Rechte(cModul: String): String;
Begin
  If AnsiCompareText(cModul, 'Angebot') = 0 Then
    Result := 'FAngebot'
  Else If AnsiCompareText(cModul, 'Auftrag') = 0 Then
    Result := 'FAuftrag'
  Else If AnsiCompareText(cModul, 'AV') = 0 Then
    Result := 'FAV'
  Else If AnsiCompareText(cModul, 'Fertigung') = 0 Then
    Result := 'FFertigung'
  Else If AnsiCompareText(cModul, 'Einkauf') = 0 Then
    Result := 'FEinkauf'
  Else If AnsiCompareText(cModul, 'Versand') = 0 Then
    Result := 'FVersand'
  Else If AnsiCompareText(cModul, 'Reparatur') = 0 Then
    Result := 'FReparatur'
  Else If AnsiCompareText(cModul, 'Supply') = 0 Then
    Result := 'FSupply'
  Else If AnsiCompareText(cModul, 'Kunden') = 0 Then
    Result := 'FKunden'
  Else If AnsiCompareText(cModul, 'Artikel') = 0 Then
    Result := 'FLager'
  Else If AnsiCompareText(cModul, 'Projekt') = 0 Then
    Result := 'FProjekt'
  Else If AnsiCompareText(cModul, 'Zeichnung') = 0 Then
    Result := 'FZeichnung'
  Else If AnsiCompareText(cModul, 'Pruefmtl') = 0 Then
    Result := 'FPruefmtl'
  Else If AnsiCompareText(cModul, 'Iso9000') = 0 Then
    Result := 'FIso9000'
  Else If AnsiCompareText(cModul, 'System') = 0 Then
    Result := 'FSystem'
  Else If AnsiCompareText(cModul, 'Dokument') = 0 Then
    Result := 'FDok'
  Else
    Result := '';
End;

Und ich habe weder Warnung noch sonst was bekommen.

Welche Delphi ver hast du denn da zum Kompilieren genutzt ?
( Meine war D5 Prof )

[hsg]

Zitat:

Zitat von Corpsman

hmm ich komm da nu nich ganz mit.

Ich habe es mal durch meinen Codeformater gejagt und von meinem Compiler Compilieren lassen.

Und ich habe weder Warnung noch sonst was bekommen.

Welche Delphi ver hast du denn da zum Kompilieren genutzt ?
( Meine war D5 Prof )

D2006 Prof und ich habe es eben noch einmal mit deinem Source probiert und bekomme die Warnung.
Wie steht denn dein Warning-Level vom Compiler? Warnungen an? "Der Rückgabewert der Funktion könnte undefiniert sein" eingeschaltet?

[hsg]

Zitat:

Zitat von hoika

Hallo,

Notlösung wäre, intern in 2 Methoden aufzusplitten.


Heiko

Wäre eben nur eine Notlösung und wenn ich an der Methode noch mal Hand anlege, wird sie eh umgeschrieben (siehe weiter oben). Es ging mir nur darum die Compiler-Meldung zu verstehen, da ich keinen Grund für sie gefunden habe.

Da es scheinbar ein Bug im Compiler ist, habe ich jetzt den entsprechenden Abschnitt mittels Warning OFF/ON ausgeklammert und kann nun meinen Source wieder ohne Warnings compilieren.

[Corpsman]

Komisch

habe grad

Delphi-Quellcode:

Function Recht(Value: String): String;
Begin
End;

Procedure TForm1.Button1Click(Sender: TObject);
Begin
  showmessage(recht('va'));
End;

geschrieben, und normalerweise gibts da ne Fehlermeldung nur diesmal nicht ?

[hsg]

Zitat:

Zitat von Corpsman

Komisch

habe grad

Delphi-Quellcode:

Function Recht(Value: String): String;
Begin
End;

Procedure TForm1.Button1Click(Sender: TObject);
Begin
  showmessage(recht('va'));
End;

geschrieben, und normalerweise gibts da ne Fehlermeldung nur diesmal nicht ?

Eine Fehlermeldung wohl eher nicht, sondern nur eine Warnung (eben die, um die es in diesem Thread geht).

Deine Warnungen sind ja wohl eingeschaltet, scheinbar gibt es dort diese Warnung noch nicht

[hoika]

Hallo,

unter D6 kommt auch keine.


Heiko

[Hawkeye219]

Variablen und Rückgabewerte vom Typ "string" (dynamische Strings) sind immer mit einem Leerstring vorbesetzt. Der Compiler erzeugt unsichtbaren Code zum Initialisieren dieser Werte. Lediglich in Sonderfällen kann es notwendig sein, mit der Prozedur Initialize nachzuhelfen.

Gruß Hawkeye