AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Tutorials Delphi Tutorial: Warnungen und Hinweise vom Delphi Compiler
Tutorial durchsuchen
Ansicht
Themen-Optionen

Tutorial: Warnungen und Hinweise vom Delphi Compiler

Ein Tutorial von MaBuSE · begonnen am 1. Aug 2007 · letzter Beitrag vom 27. Jun 2013
Antwort Antwort
Seite 2 von 2     12   
Benutzerbild von MaBuSE
MaBuSE
Registriert seit: 23. Sep 2002
Tutorial
Warnungen und Hinweise vom Delphi Compiler



Autor: MaBuSE für www.delphipraxis.net
Stand: 02.08.2007
(c) 2007, MaBuSE
Es wurden Teile der Onlinehilfe von Delphi 7 und Delphi 2007 verwendet
(c) 1995-2007 Borland Software Corporation
Vielen Dank auch an Phoenix für die Anregung das hier zu schreiben
Mein besonderer Dank für die Arbeit in der DP und Unterstützung für mich geht an:
Daniel, Sakura, Gerome und an alle Moderatoren



Warum dieses Tutorial?
Lieber Delphi Programmierer,
mir ist aufgefallen, dass es Bedarf an einem Tutorial zu dem Thema Warnungen und Hinweise gibt.
Man kann einzelne Gruppen von Warnungen aus- und einschalten, alle Warnungen ausschalten, alle Hinweise ausschalten aber auch eigene Hinweise und Warnungen erzeugen.
Das alles wird in diesem Tutorial beschrieben.
Ich möchte die Gelegenheit nutzen und auch noch auf folgende Tutorials hinweisen:Ein kleines Inhaltsverzeichnis dieses Tutorials:
  1. Was ist ein(e) Fehler / Warnung / Hinweis?
  2. Warum wirft Delphi eine Warnung aus? Ich habe doch alles richtig gemacht.
  3. Alle Warnungen / Hinweise an- und abschalten
  4. Einzelne Warnungen abschalten
  5. Eigene Fehler / Warnungen / Hinweise erzeugen
  6. Tipp: Einstellungen in *.inc Dateien auslagern
  7. Tipp: aktuelle Einstellungen in den Quelltext einfügen
  8. Eine Liste aller Warnungen und der zugehörigen Schalter zum an- / abschalten
  9. Wie kann ich meine Symbole oder Units als veraltet, bibliotheksspezifisch, platformabhängig oder experimentell kennzeichen?
  1. Was ist ein(e) Fehler / Warnung / Hinweis?
    Der Compiler übersetzt den Quelltext in eine binäre Datei, die dann ausgeführt werden kann (*.exe, *.dll, *.bpl, ...)
    Der zu kompilierende Quelltext ist von Menschen geschrieben, und die machen Fehler (manchmal).

    Warnungen:
    Einige der potenziellen Fehlerquellen kann der Compiler erkennen und gibt eine Warnung aus.
    Diese Warnungen sind keine Fehler, der Compiler kann das Programm übersetzen und es sollte auch laufen.
    Trotzdem macht es Sinn sich die Warnungen genau anzuschauen, da es oft kein Problem ist die Warnung zu beseitigen und der Quellcode damit an Qualität gewinnt.
    Und manch ein Programmierer hat schon viele Stunden einen Bug gesucht, der durch eine Warnung entstanden ist.

    Ein Beispiel:
    Delphi-Quellcode:
    ...
    function test(i: Integer): Boolean;
    begin
      if i > 0 then Result := True;
    end;
    ...
    Der Compiler wirft folgende Warnung raus: Rückgabewert der Funktion 'test' könnte undefiniert sein
    Wenn i<=0 ist ist der Rückgabewert nicht definiert. Es kann also True oder False sein.
    Eine Einfache Lösung ist es den Rückgabewert am Anfang der Funktion zu definieren:
    Delphi-Quellcode:
    ...
    function test(i: Integer): Boolean;
    begin
      Result := False;
      if i > 0 then Result := True;
    end;
    ...
    Es gibt aber auch noch viele andere Lösungen:
    Delphi-Quellcode:
    ...
    function test(i: Integer): Boolean;
    begin
      if i > 0 then Result := True else Result := False;
    end;
    ...
    oder
    Delphi-Quellcode:
    ...
    function test(i: Integer): Boolean;
    begin
      Result := i > 0;
    end;
    ...

    Hinweise:
    Hinweise sind nicht ganz so schlimm wie Warnungen. Von Ihnen geht keine so große Gefahr aus.
    Trotzdem kann man die Qualität seines Quelltextes erhöhen, in dem man die Hinweise beseitigt.

    Ein Beispiel:
    Delphi-Quellcode:
    ...
    function test(i: Integer): Boolean;
    var
      x: Integer;
    begin
      Result := i > 0;
    end;
    ...
    Der Compiler wirft folgenden Hinweis aus: Variable 'x' wurde deklariert, aber in 'test' nicht verwendet
    Das stimmt und ist eigentlich auch nicht weiter schlimm. Aber der Quelltext wird übersichtlicher, wenn x entfernt wird.

    Oder folgendes Beispiel:
    Delphi-Quellcode:
    ...
    function test(i: Integer): Boolean;
    var
      x: Integer;
    begin
      x := 0;
      
      x := i;
      Result := x > 0;
    end;
    ...
    Der Compiler wirft folgenden Hinweis für die Zeile 6 aus: Auf 'x' zugewiesener Wert wird niemals benutzt
    Das stimmt und man kann die Zuweisung x := 0; entfernen.

    Diese 2 Hinweise treten erfahrungsgemäß am häufigsten auf. und sind auch relativ leicht zu entfernen.

    Tipp: Ich empfehle Dir immer zu versuchen Programme zu erstellen, die keine Hinweise und Warnungen enthalten.

    Fehler:
    Bei einem Fehler kann der Compiler seine Arbeit nicht erfolgreich abschließen und unterbricht diese.
    Es gibt 2 Arten von Fehlern:
    1. Fatal
      Bei einem fatalen Fehler unterbricht der Compiler seine Arbeit sofort an der Stelle wo der Fehler auftrat.
    2. Error
      Das ist der normale Fehler. Der Compiler unterbricht das Kompilieren nicht sofort, sondern compiliert die Unit noch weiter.
      Am Ende der Unit wird noch mal ein "fataler Fehler" (Unit '<Element>' kann nicht erzeugt werden.) erzeugt und der Compiler unterbricht dann seine Arbeit.
  2. Warum wirft Delphi eine Warnung aus? Ich habe doch alles richtig gemacht.
    Machmal kommt eine Warnung z.B. Variable 'x' ist möglicherweise nicht initialisiert worden.
    Es wurde aber von mir im Beispiel unten ganz eindeutig x der Wert 1 zugewiesen.
    Warum gibt es die Warnung?
    Delphi-Quellcode:
    ...
    function test(i: Integer): Integer;
    var
      x: integer;
    begin
      try
        x := 1;
      except
        ShowMessage('Es ist ein Fehler aufgetreten, der abgefangen wurde');
      end;

      Result := i + x;
    end;
    ...
    Delphi geht davon aus, das alles was in einem try ... except Block steht, potentiell nicht ausgeführt wird.
    Wenn wir nun die Zeile "if i>0 then StrToInt('Zwei');" einfügen, sehen wir warum.
    Wird der Funktion Test ein negativer Wert übergeben, so wird die Exception "Zwei" ist kein gültiger Integer-Wert ausgelöst.
    x := 1; wird übersprungen und es wird die Dialogbox angezeigt. Wenn nun OK gedrückt wird, wird mit Result := i + x; auf einen nicht definierten Wert zugegriffen.
    Damit gibt Die Funktion einen nicht definierten Wert zurück. (Das kann i + 0 sein, muß aber nicht.)
    Delphi-Quellcode:
    ...
    function test(i: Integer): Integer;
    var
      x: integer;
    begin
      try
        if i<0 then StrToInt('Zwei');
        x := 1;
      except
        ShowMessage('Es ist ein Fehler aufgetreten, der abgefangen wurde');
      end;

      Result := i + x;
    end;
    ...
    Oft sieht man auch folgendes:
    Delphi-Quellcode:
    ...
    procedure test;
    var
      o: TObject;
    begin
      try
        o := TObject.Create;
        machWasMit(o);
      finally
        o.Free;
      end;
    end;
    ...
    Hier gibt der Delphi Compiler auch eine Warnung bei der o.Free Zeile aus: Variable 'o' ist möglicherweise nicht initialisiert worden.
    Das ist genau das Gleiche.
    So soll try finally nicht verwendet werden! Das macht keinen Sinn. Falls in "TObject.Create;" oder "MachWasMit(o);" ein Fehler auftritt, fängt try...finally die Exception, und springt in den finally Block. Es werden nun die Befehle zwischen finally und end ausgeführt. Beim Erreichen des end; wird dann die gefangene Exception ausgelöst. Und die Prozedur bricht an der Stelle ab.
    Richtig ist folgendes Beispiel (gleiches Verhalten, aber keine Warnung).
    Delphi-Quellcode:
    ...
    procedure test;
    var
      o: TObject;
    begin
      o := Tobject.Create;
      try
        machWasMit(o);
      finally
        o.Free;
      end;
    end;
    ...
    Das kann man auch noch mal im Exceptional exceptions im Developer Network von CodeGear nachlesen.
    Mehr will ich hier gar nicht zu Exceptions schreiben, da könnte man locker ein eigenes Tutorial draus machen.
  3. Alle Warnungen / Hinweise an- und abschalten
    Allgemein kann man Warnungen in den Projektoptionen ein- und ausschalten.
    ( Menu -> Projekt -> Projekt-Optionen -> Compiler-Meldungen )

    Mit der Compiler Direktive {$WARNINGS ON|OFF} kann man auch im Quelltext die Warnungen gezielt an und ausschalten.
    z.B.
    Delphi-Quellcode:
    ...
      {$WARNINGS OFF}
      // hier mache ich was ganz schlimmes was gaaanz viele Warnungen produziert
    ...
      {$WARNINGS ON}
      // ab hier wieder Warnungen ausgeben :-)
    ...
    Mit {$HINTS ON|OFF} kann man analog dazu die Hinweise an- und abschalten.
  4. Einzelne Warnungen abschalten
    Es ist auch möglich einzelne Warnungen ein- bzw. auszuschalten.
    Dazu wird die Direktive {$WARN WARNUNG_TYP ON|OFF} verwendet. Weiter unten findest Du eine Liste der Warnungstypen inklusive Erklärungen.
  5. Eigene Fehler / Warnungen / Hinweise erzeugen
    Mit der $MESSAGE Direktive kann man eigene Hinweise, Warnungen und Fehler beim Compile ausgeben.

    Das steht dazu in der Delphi 7 Hilfe:
    MESSAGE (Direktive)

    Syntax{$MESSAGE HINT|WARN|ERROR|FATAL 'Textstring' } Anmerkungen
    • Diese Direktive ermöglicht dem Quelltext, wie der Compiler Hinweise, Warnungen und Fehlermeldungen zu generieren. Sie ähnelt den Anweisungen #emit und pragma warn in C/C++.
      Der Meldungstyp (HINT, WARN, ERROR oder FATAL) ist optional. Ohne diese Angabe wird HINT verwendet. Der Textstring muss angegeben und in einfache Anführungszeichen eingeschlossen werden.
    Beispiele:
    Delphi-Quellcode:
    {$MESSAGE 'Boo!'} //Hinweis

    {$Message Hint 'Füttere die Katzen'}    // Hinweis
    {$messaGe Warn 'Sieht nach Regen aus.'} // Warnung
    {$Message Error 'Nicht implementiert'}  // Fehler, die Compilierung wird fortgesetzt
    {$Message Fatal 'Bang.  Tot.'} // Fehler, die Compilierung wird abgebrochen


  6. Tipp: Einstellungen in *.inc Dateien auslagern
    Es macht Sinn seine Optionen in einer *.inc Datei festzuhalten und diese dann in jede Unit einzubinden.
    Delphi-Quellcode:
    ...
    {$I myCompilerOptions.inc}
    ...
    So ist gewährleistet, dass alle Units mit den gleichen Einstellungen kompiliert werden und das auf einem anderem PC auch diese Einstellungen zum kompilieren verwendet werden.
  7. Tipp: aktuelle Einstellungen in den Quelltext einfügen
    In dem Quelltexteditor kann man [Strg]+[O]+[O] drücken.
    Dann fügt Delphi am Anfang der Datei alle Compileroptionen und alle Warnungen Einstellungen ein.
    Die kann man ausschneiden und in die *.inc Datei verschieben.
  8. Eine Liste aller Warnungen und der zugehörigen Schalter zum an- / abschalten
    Ich habe in Delphi 7 und in Delphi 2007 nachgeschaut und die Optionen hier mal dokumentiert.
    Die Informationen kommen größtenteils aus der Delphi 7 Hilfe bzw. der von Delphi 2007.
    Bei einigen Direktiven habe ich noch eigene Ergänzungen hinzugefügt.
    • Diese sind in Delphi 7 verfügbar:
    • {$WARN SYMBOL_DEPRECATED ON}
      Warnung: Symbol '<Element>' wird abgelehnt oder Symbol '<Element>' ist veraltet
      Das Symbol ist (mit der Hinweisdirektive deprecated) als nicht mehr aktuell gekennzeichnet und nur aus Kompatibilitätsgründen vorhanden. Verwende möglichst ein anderes Symbol in Deinem Quelltext.
    • {$WARN SYMBOL_LIBRARY ON}
      Warnung: Symbol '<Element>' ist bibliotheksspezifisch
      Das Symbol ist (mit der Hinweisdirektive library) als nicht in allen Bibliotheken verfügbar gekennzeichnet. Wenn Du andere Bibliotheken verwendest, kann dies zu Problemen führen.
    • {$WARN SYMBOL_PLATFORM OFF}
      Warnung: Symbol '<Element>' ist plattformspezifisch
      Das Symbol ist (mit der Hinweisdirektive platform) als nicht auf allen Plattformen verfügbar gekennzeichnet. Wenn Du plattformübergreifende Anwendungen erstellst, kann dies zu Problemen führen.
      Mit Platform ist Windows / Linux gemeint. Meist bedeutet das, das man eine Funktion verwendet, die nur unter Windows verfügbar ist.
      Ich habe diese Warnung immer abgeschaltet, da ich ausschliesslich Software für Windows entwickle.
    • {$WARN UNIT_LIBRARY ON}
      Warnung: Unit '<Element>' ist bibliotheksspezifisch
      Die gesamte Unit ist (mit der Hinweisdirektive library) als eine gekennzeichnet, die nicht in allen Bibliotheken zur Verfügung steht. Wenn Du andere Bibliotheken verwendest, kann dies zu Problemen führen.
    • {$WARN UNIT_PLATFORM OFF}
      Warnung: Unit '<Element>' ist plattformspezifisch
      Die gesamte Unit ist (mit der Hinweisdirektive platform) als eine gekennzeichnet, die Inhalte enthält, die nicht auf allen Plattformen verfügbar sind. Wenn Du plattformübergreifende Anwendungen erstellst, kann dies zu Problemen führen. Beispielsweise wird platform bei Units mit Objekten angegeben, die in OleAuto definiert sind.
      Mit Platform ist Windows / Linux gemeint. Meist bedeutet das, das man eine Unit verwendet, die nur unter Windows verfügbar ist.
    • {$WARN UNIT_DEPRECATED ON}
      Warnung: Unit '<Element>' wird abgelehnt oder Unit '<Element>' ist veraltet
      Die Unit ist veraltet und nur aus Gründen der Abwärtskompatibilität vorhanden.
      Die Unit ist (mit der Hinweisdirektive deprecated) als nicht mehr aktuell gekennzeichnet und nur aus Kompatibilitätsgründen vorhanden. Verwende möglichst eine andere Unit in Deinem Quelltext.
    • {$WARN HRESULT_COMPAT ON}
      Warnung: Integer und HResult werden ausgetauscht
      Integer, Longint und HRESULT sind in Delphi kompatible Typen. In C++ sind sie jedoch nicht kompatibel und erzeugen unterschiedlich verkürzte C++ Parameternamen. Diese Meldung soll sicherstellen, dass es beim Linken von Objektdateien, die Du mit dem Delphi-Compiler erzeugt hast, keine Probleme gibt. Wenn Du eine Objektdatei compilierst, ergibt sich daraus ein Fehler. Andernfalls ist die Meldung als Warnung zu betrachten.
    • {$WARN HIDING_MEMBER ON}
      Warnung: Redeklaration von '<Element>' verbirgt ein Mitglied (Member) in der Basisklasse
      In einer Klasse wurde eine Eigenschaft erstellt, die dieselbe Bezeichnung wie eine Variable in einer der Basisklassen hat. Eine mögliche, aber nicht immer offensichtliche Ursache für diesen Fehler liegt darin, dass eine neue Version der Basisklassen-Hierarchie installiert wurde, die neue Mitgliedvariablen aufweist, deren Bezeichnungen mit den Bezeichnungen Ihrer Eigenschaften identisch sind.
    • {$WARN HIDDEN_VIRTUAL ON}
      Warnung: Methode '<Element>' verbirgt virtuelle Methode vom Basistyp '<Element>'
      Du hast eine Methode deklariert, die dieselbe Bezeichnung wie eine virtuelle Methode in der Basisklasse hat. Diese neue Methode ist keine virtuelle Methode und wird den Zugriff auch die gleichnamige Basismethode verbergen.
    • {$WARN GARBAGE ON}
      Warnung: Text hinter dem abschließenden 'END.' wird vom Compiler ignoriert
      Diese Warnmeldung wird angezeigt, wenn sich nach dem abschließenden end und dem Punkt, der das logische Ende des Programms bildet, weiterer Quelltext befindet. Wahrscheinlich ist die Verschachtelung von begin..end inkonsistent (irgendwo ist ein "end" zu viel). Überprüfe, ob der Quelltext wirklich vom Compiler ignoriert werden sollte – möglicherweise ist er recht bedeutend.
    • {$WARN BOUNDS_ERROR ON}
      Warnung: Konstantenausdruck verletzt die Grenzen des Unterbereichs
      Diese Fehlermeldung tritt auf, wenn der Compiler feststellt, dass eine Konstante außerhalb der zulässigen Grenzen liegt. Dies kann beispielsweise dann eintreten, wenn Du eine Konstante einer unterdimensionierten Variablen zuweist.
    • {$WARN ZERO_NIL_COMPAT ON}
      Warnung: Konstante 0 wurde zu NIL konvertiert
      Der Delphi-Compiler erlaubt es nun, die Konstante 0 in Zeigerausdrücken anstelle von nil zu verwenden. Dadurch kann alter Quelltext compiliert werden, der Änderungen in der RTL enthält.
    • {$WARN STRING_CONST_TRUNCED ON}
      Warnung: Stringkonstante abgeschnitten damit sie in STRING[<Zeilennummer>] passt
      Eine Stringkonstante wird einer Variablen zugewiesen, die nicht groß genug ist, um den gesamten String aufnehmen zu können. Der Compiler gibt eine Warnung aus, dass das Literal entsprechend der Variablengröße abgeschnitten wurde.
    • {$WARN FOR_LOOP_VAR_VARPAR ON}
      Warnung: FOR-Schleifenvariable '<Element>' kann nicht als Var-Parameter übergegeben werden
      Du hast versucht, die Steuervariable einer for-Schleife an eine Prozedur oder Funktion zu übergeben, die einen var-Parameter erwartet. Dies ist eine Warnung, weil die Variable in der Routine geändert werden kann und dadurch die Semantik der for-Schleife verändert wird.
    • {$WARN TYPED_CONST_VARPAR ON}
      Warnung: Typisierte Konstante '<Element>' als Var-Parameter übergegeben
      Dies ist eine reservierte Fehlermeldung.
    • {$WARN ASG_TO_TYPED_CONST ON}
      Warnung: Zuweisung für typisierte Konstante '<Element>'
      Diese Warnmeldung wird momentan nicht verwendet.
    • {$WARN CASE_LABEL_RANGE ON}
      Warnung: Case-Label außerhalb des Bereichs des Case-Ausdrucks
      Du hast innerhalb einer case-Anweisung ein Label angegeben, das von der Steuervariable der case-Anweisung nicht erzeugt werden kann.
    • {$WARN FOR_VARIABLE ON}
      Warnung: FOR-Schleifenvariable muss eine einfache lokale Variable sein
      Diese Fehlermeldung wird angezeigt, wenn die Steuervariable einer for-Anweisung keine einfache Variable ist (sondern beispielsweise eine Komponente eines Datensatzes), und wenn sie nicht lokal zu der Prozedur ist, die die for-Anweisung enthält.
      Aus Gründen der Abwärtskompatibilität ist es zulässig, eine globale Variable als Steuervariable zu verwenden – der Compiler gibt in diesem Fall eine Warnmeldung aus. Beachte, dass mit Verwendung einer lokalen Variable außerdem ein leistungsfähigerer Programmcode erzeugt wird.
    • {$WARN CONSTRUCTING_ABSTRACT ON}
      Warnung: Instanz von '<Element>' mit abstrakter Methode '<element>.<element>' wird konstruiert
      Der zu compilierende Quelltext konstruiert Instanzen von Klassen, die abstrakte Methoden enthalten.
      Eine abstrakte Prozedur existiert nicht, so dass es gefährlich wird, Instanzen einer Klasse zu erstellen, die abstrakte Prozeduren enthält.
      -> Laufzeitfehler
    • {$WARN COMPARISON_FALSE ON}
      Warnung: Der Vergleich ergibt immer False
      Der Compiler hat festgestellt, dass ein Ausdruck immer den Wert False liefert. Dies ist in den meisten Fällen das Ergebnis eines Randtests, wobei ein Vergleich mit einem bestimmten Variablentyp erfolgt. Beispiel: Ein Integer verglichen mit $80000000.
      In früheren Versionen des Delphi-Compilers (vor 12.0) wäre die Hexadezimal-Konstante $80000000 als negativer Integerwert definiert gewesen, aber durch die Einführung des Typs Int64 ist $80000000 nun ein positiver Wert des Typs Int64. Dies hat zur Folge, dass Vergleiche dieser Konstante mit Integer-Variablen nicht mehr die gleichen Ergebnisse liefern wie in früheren Versionen.
      Für den Umgang mit dieser Warnung gibt es kein Patentrezept. Manchmal kann sie ignoriert werden, aber in anderen Fällen ist es erforderlich, den Quelltext entsprechend zu ändern.
    • {$WARN COMPARISON_TRUE ON}
      Warnung: Der Vergleich ergibt immer True
      Der Compiler hat festgestellt, dass ein Ausdruck immer den Wert True liefert. Dies ist in den meisten Fällen das Ergebnis eines Randtests, wobei ein Vergleich mit einem bestimmten Variablentyp erfolgt. Beispiel: Ein Integer verglichen mit $80000000.
      In früheren Versionen des Borland Pascal-Compilers (vor 12.0) wäre die Hexadezimal-Konstante $80000000 als negativer Integerwert definiert gewesen, aber durch die Einführung des Typs Int64 ist $80000000 nun ein positiver Wert des Typs Int64. Dies hat zur Folge, dass Vergleiche dieser Konstante mit Integer-Variablen nicht mehr die gleichen Ergebnisse liefern wie in früheren Versionen.
      Für den Umgang mit dieser Warnung gibt es kein Patentrezept. Manchmal kann sie ignoriert werden, aber in anderen Fällen ist es erforderlich, den Quelltext entsprechend zu ändern.
    • {$WARN COMPARING_SIGNED_UNSIGNED ON}
      Warnung: Vorzeichenbehaftete und -lose Typen werden verglichen - beide Operanden werden erweitert
      Zum korrekten Vergleichen von Typen mit und ohne Vorzeichen muss der Compiler beide Operanden auf den nächstgrößeren gemeinsamen Datentyp "hochstufen".
      Um zu sehen, warum die Typänderung erforderlich ist, betrachte zwei Operanden, nämlich Shortint mit dem Wert -128 und Byte mit dem Wert 130. Der Typ Byte weist eine Stelle mehr an Genauigkeit auf als der Typ Shortint, so dass der Vergleich der beiden Werte über nur 8 Bit nicht exakt erfolgen kann. Die Lösung für den Compiler besteht darin, beiden Typen auf eine nächsthöhere gemeinsame Größe zu erweitern und dann den Vergleich durchzuführen.
    • {$WARN COMBINING_SIGNED_UNSIGNED ON}
      Warnung: Vorzeichenbehaftete und -lose Typen werden kombiniert - beide Operanden werden erweitert
      Zum mathematischen Kombinieren von Typen mit und ohne Vorzeichen erweitert der Compiler zunächst beide Operanden auf einen nächstgrößeren gemeinsamen Datentyp.
      Um zu sehen, warum die Typänderung erforderlich ist, betrachte zwei Operanden, nämlich Integer mit dem Wert -128 und Cardinal mit dem Wert 130. Der Typ Integer weist eine Stelle mehr an Genauigkeit auf als der Typ Cardinal, so dass der Vergleich der beiden Werte über nur 32 Bit nicht exakt erfolgen kann. Die Lösung für den Compiler besteht darin, beiden Typen auf eine nächsthöhere gemeinsame Größe zu erweitern und dann den Vergleich durchzuführen.
      Der Compiler zeigt diese Warnung nur, wenn die Größe die zur Berechnung des Ergebnisses übliche Größe überschreitet.
    • {$WARN UNSUPPORTED_CONSTRUCT ON}
      Warnung: Sprach-Feature wird nicht unterstützt: '<Element>'
      Beim Versuch, eine Delphi-Unit in eine C++ Header-Datei zu übersetzen, wurden in der Unit Sprachelemente entdeckt, die nicht unterstützt werden.
      Damit die Unit übersetzt werden kann, muss das fehlerhafte Konstrukt aus dem interface-Abschnitt entfernt werden.
    • {$WARN FILE_OPEN ON}
      Warnung: Datei nicht gefunden: '<Element>'
      Diese Fehlermeldung tritt auf, wenn der Compiler eine Eingabedatei nicht finden kann. Es kann sich hierbei um eine Quelldatei, eine compilierte Unit-Datei (.dcu-Datei), eine Include-Datei, eine Objektdatei oder eine Ressourcendatei handeln.
      Überprüfe die Schreibweise der Bezeichnung und den entsprechenden Suchpfad.
      Bei einer .dcu-Datei ist eine wahrscheinlich Ursache für diese Meldung ein vergessener Unit-/Bibliothekspfad für den Compiler. Die einzige Lösung ist, sicherzustellen, dass die Unit über den Bibliothekspfad gefunden werden kann.
    • {$WARN FILE_OPEN_UNITSRC ON}
      Warnung: ???
      Zu dieser Warnung habe ich keine Infos gefunden.
    • {$WARN BAD_GLOBAL_SYMBOL ON}
      Warnung: Falsche globale Symboldefinition: '<Element>' in Objektdatei '<Element>'
      Diese Warnung wird angezeigt, wenn eine mit der Direktive $L oder $LINK eingebunde Objektdatei die Definition eines Symbols enthält, das in Delphi nicht als externe Prozedur deklariert wurde, sondern als etwas anderes (z. B. als Variable).
      Die Symboldefinition wird in diesem Fall ignoriert.
    • {$WARN DUPLICATE_CTOR_DTOR ON}
      Warnung: <Element> '<Element>' doppelt mit identischen Parametern; Zugriff von C++ nicht möglich
      Es wird eine Objektdatei erzeugt, und zwei unterschiedlich benannte Konstruktoren oder Destruktoren mit identischen Parameterlisten wurden erzeugt. Auf sie kann bei der Umsetzung des Quelltext in eine HPP-Datei nicht zugegriffen werden, weil sowohl die Konstruktor- als auch die Destruktor-Namen in den Klassennamen konvertiert werden. In C++ erscheinen diese doppelt vorhandenen Deklarationen als ein und dieselbe Funktion.
    • {$WARN INVALID_DIRECTIVE ON}
      Warnung: Ungültige Compiler-Direktive: '<Element>'
      Diese Meldung wird angezeigt, wenn eine Compiler-Direktive oder Befehlszeilenoption einen Fehler enthält. Die folgende Aufstellung zeigt einige der möglichen Ursachen:
      • Eine externe Deklaration enthält Syntaxfehler.
      • Eine Befehlszeilenoption oder eine Option in der Datei DCC32.CFG ist fehlerhaft oder wurde vom Compiler nicht erkannt . So ist beispielsweise die Option "-$M100" ungültig, da die minimale Stack-Größe mindestens 1024 sein muss.
      • Der Compiler hat eine $XXXXX-Direktive gefunden, aber nicht erkannt. Sie enthält wahrscheinlich einen Syntaxfehler.
      • Der Compiler hat die Direktive $ELSE oder $ENDIF, aber kein vorhergehendes $IFDEF, $IFNDEF oder $IFOPT gefunden.
      • Nach (*$IFOPT*) wurde kein Schalter mit dem Zeichen + oder - eingegeben.
      • Nach der langen Form einer Direktive fehlt ON oder OFF.
      • Auf eine Direktive mit einem numerischen Parameter folgt keine gültige Zahl.
      • Nach der Direktive $DESCRIPTION wurde kein String eingegeben.
      • Nach der Direktive $APPTYPE wurde nicht CONSOLE oder GUI eingegeben.
      • Nach der Direktive $ENUMSIZE (Kurzform $Z) wurde nicht 1, 2 oder 4 eingegeben.
    • {$WARN PACKAGE_NO_LINK ON}
      Warnung: Package '<Element>' wird nicht auf Platte geschrieben, da Option –J aktiviert ist
      Der Compiler kann das Package nicht auf die Festeplatte schreiben, da die Option -J versucht, eine Objektdatei zu erstellen.
    • {$WARN PACKAGED_THREADVAR ON}
      Warnung: Die exportierte Package-Thread-Variable '<Element>.<Element>' darf nicht außerhalb dieses Package verwendet werden
      Windows unterstützt das Exportieren von threadvar-Variablen aus einer DLL zwar nicht, aber da die Verwendung von Packages als semantisch gleichwertig mit der Compilierung eines Projekts ohne diese Packages definiert ist, muss der Delphi-Compiler dieses Konstrukt unterstützen.
      Mit dieser Warnung wirst Du darüber informiert, dass Du eine Unit mit einbezogen hast, die eine lokal gültige Schnittstellenvariable für einen Thread in einem Package verwendet. Da dies unzulässig ist, hast Du aus einer Unit außerhalb des Package keinen Zugriff auf die Variable.
      Ein entsprechender Zugriffsversuch ist nur scheinbar erfolgreich.
      Eine Lösung besteht darin, die threadvar-Variable in den Implementierungsabschnitt zu verschieben und eine Funktion zur Verfügung zu stellen, die den Wert der Variablen abruft.
    • {$WARN IMPLICIT_IMPORT ON}
      Warnung: Die Unit '<Element>' wurde implizit in Package '<Element>' importiert
      Die angegebene Unit war in der contains-Klausel des Package nicht vorhanden, wird aber von einer Unit importiert, die bereits im Package existiert.
      Diese Meldung weist den Programmierer darauf hin, dass er gegen folgende Regel verstoßen hat: Eine Unit darf nicht in mehreren verwandten Packages vorhanden sein.
      Das Ignorieren dieser Warnung führt zum Einfügen der Unit in das Package. Wenn Du die genannte Unit explizit in der contains-Klausel des Package auflistest, erzielst Du dasselbe Ergebnis und verhindern die Anzeige dieser Warnung. Du kannst aber auch die Package-Liste ändern, um die genannte Unit aus einem anderen Package zu laden.
      Die beste Lösung für dieses Problem besteht darin, explizit alle Units in der contains-Klausel aufzulisten, die in das Package importiert werden.
    • {$WARN HPPEMIT_IGNORED ON}
      Warnung: $HPPEMIT '<Element>' wird ignoriert
      Die Anweisung $HPPEMIT darf nur im Unit-Header vorkommen.
    • {$WARN NO_RETVAL ON}
      Warnung: Rückgabewert der Funktion '<Element>' könnte undefiniert sein
      Diese Warnung wird angezeigt, wenn dem Rückgabewert einer Funktion nicht in jedem Codepfad ein Wert zugewiesen wurde.
      Die Funktion könnte auch ausgeführt werden, ohne dass der Rückgabewert zugewiesen wird.
      Die Lösung besteht darin, sicherzustellen, dass der Rückgabewert in jedem möglichen Quelltextpfad zugewiesen wird.
    • {$WARN USE_BEFORE_DEF ON}
      Warnung: Variable '<Element>' ist möglicherweise nicht initialisiert worden
      Diese Warnung wird angezeigt, wenn einer Variablen nicht in jedem Codepfad, der zu der Stelle führt, an der sie verwendet wird, ein Wert zugewiesen wird.
      Du mußt in einer if-Anweisung sicherstellen, dass die Variable in beiden Verzweigungen zugewiesen wird. Bei einer case-Anweisung muss ein else-Abschnitt hinzugefügt werden, damit die Variable in jedem möglichen Fall einen Wert erhält. Bei einem try-except-Konstrukt geht der Compiler davon aus, dass die Anweisungen im try-Abschnitt auch dann nicht ausgeführt werden, wenn Du dich am Anfang des Abschnitts befindest und so einfach sind, dass eigentlich keine Exception auftreten kann.
      Die Lösung besteht entweder darin, Zuweisungen zu allen Quelltextpfaden hinzuzufügen, oder die Variable bereits vor einer Bedingungsanweisung oder einem try-except-Konstrukt zuzuweisen.
    • {$WARN FOR_LOOP_VAR_UNDEF ON}
      Warnung: FOR-Schleifenvariable '<Element>' kann nach Durchlauf undefiniert sein
      Diese Warnung wird angezeigt, wenn die Steuervariable einer for-Schleife nach der Schleife verwendet wird.
      Du kannst dich nur auf den letzten Wert eines for-Schleifenzählers verlassen, wenn die Schleife mit einer goto- oder exit-Anweisung verlassen wird.
      Der Grund für diese Einschränkung ist, dass der Compiler dadurch sehr effizienten Code für die for-Schleife erzeugen kann.
    • {$WARN UNIT_NAME_MISMATCH ON}
      Warnung: Unit-Bezeichner '<Element>' stimmt mit dem Dateinamen nicht überein
      Da bei dem Unit-Namen in der obersten Unit zwischen Groß- und Kleinschreibung unterschieden wird, muss die Schreibweise genau übereinstimmen. Beim Unit-Namen findet diese Unterscheidung nur in der Unit-Deklaration statt.
    • {$WARN NO_CFG_FILE_FOUND ON}
      Warnung: Es wurden keine Konfigurationsdateien gefunden
      Der Compiler konnte die Konfigurationsdateien nicht finden, auf die im Quelltext verwiesen wird.
    • {$WARN IMPLICIT_VARIANTS ON}
      Warnung: Implizite Verwendung der Variants-Unit
      Wenn Du in Deiner Anwendung Variantentypen verwendest, nimmt der Compiler automatisch die Unit Variant in die uses-Klausel auf, weist Dich aber darauf hin, die Datei explizit hinzuzufügen.
    • {$WARN UNICODE_TO_LOCALE ON}
      Warnung: Fehler beim Konvertieren der Unicode-Zeichen in den länderspezifischen Zeichensatz. String wurde abgeschnitten. Ist die Umgebungsvariable LANG korrekt gesetzt?
      Diese Meldung wird angezeigt, wenn Du einen Unicode-String in Ihren lokalen Zeichensatz konvertierst, und der String Zeichen enthält, die im aktuellen Gebietsschema nicht zulässig sind. Dies ist beispielsweise beim Konvertieren von WideString in AnsiString oder beim Versuch, japanische Zeichen in einem englischen Gebietsschema anzuzeigen, der Fall.
    • {$WARN LOCALE_TO_UNICODE ON}
      Warnung: Fehler beim Konvertieren des Strings '<element>' in Unicode. String wurde abgeschnitten. Ist die Umgebungsvariable LANG korrekt gesetzt?
      Diese Meldung wird angezeigt, wenn Du Strings in das Unicode-Format konvertierst und der String Zeichen enthält, die im aktuellen Gebietsschema nicht zulässig sind. Dies ist beispielsweise beim Konvertieren von WideString in AnsiString oder beim Versuch, japanische Zeichen in einem englischen Gebietsschema anzuzeigen, der Fall.
    • {$WARN IMAGEBASE_MULTIPLE ON}
      Warnung: Imagebase $<Wert> ist kein Vielfaches von 64 K. Wird auf $<Wert> abgerundet
      Du kannst mit der Direktive $IMAGEBASE eine Image-Basisadresse für eine DLL angeben, um sie an einer bestimmten Position in den Speicher zu laden. $IMAGEBASE steuert die Standard-Ladeadresse einer Anwendung, DLL oder Package-Datei. Die als Image-Basis angegebene Adresse muss ein Vielfaches von 64 K sein (d.h. eine Hexadezimalzahl mit vier Nullen am Ende). Andernfalls wird der Wert auf das nächste Vielfache abgerundet, und Du erhällst diese Fehlermeldung.
    • {$WARN SUSPICIOUS_TYPECAST ON}
      Warnung: Zweifelhafte Typumwandlung von <Element> in <Element>
      Diese Warnung wird bei Typumwandlungen wie PWideChar(String) oder PChar(WideString) angezeigt, in denen unterschiedliche String-Typen ohne Zeichenkonvertierung umgewandelt werden.
    • {$WARN PRIVATE_PROPACCESSOR ON}
      Warnung: Eigenschaftsdeklaration verweist auf private-Vorfahr '<Element>.<Element>'
      Diese Warnung weist darauf hin, dass Ihr Quelltext nicht nach C++ portierbar ist. Dies ist für Komponentenentwickler wichtig, die Ihre Steuerelemente weitergeben möchten.
      In Delphi kannst Du in derselben Unit eine Basisklasse mit einem privaten Element und eine untergeordnete Klasse deklarieren, in der auf dieses Element verwiesen wird. In C++ ist diese Konstruktion nicht zulässig. Ändere daher die untergeordnete Komponente so, dass der Verweis entweder auf ein protected-Element der Basisklasse oder auf ein protected-Element der untergeordneten Klasse erfolgt.
    • {$WARN UNSAFE_TYPE OFF}
      Warnung: Unsafe-Typ '<element><element><element>'
      Du hast einen Datentyp verwendet oder einen Vorgang ausgeführt, der möglicherweise Speicher überschreibt. In einer gesicherten Ausführungsumgebung wie beispielsweise .NET wird solcher Code als unsicher und potentiell gefährlich betrachtet.
    • {$WARN UNSAFE_CODE OFF}
      Warnung: Unsafe-Code: '<Element>'
      Du hast einen Datentyp verwendet oder einen Vorgang ausgeführt, der möglicherweise Speicher überschreibt. In einer gesicherten Ausführungsumgebung wie beispielsweise .NET wird solcher Code als unsicher und potentiell gefährlich betrachtet.
    • {$WARN UNSAFE_CAST OFF}
      Warnung: Zweifelhafte Typumwandlung von <Element> in <Element>
      Du hast einen Datentyp verwendet oder einen Vorgang ausgeführt, der möglicherweise Speicher überschreibt. In einer gesicherten Ausführungsumgebung wie beispielsweise .NET wird solcher Code als unsicher und potentiell gefährlich betrachtet.


      Zusätzlich sind folgende in D2007 verfügbar:
      (Delphi 8, 2005 und 2006 habe ich nicht geprüft)
    • {$WARN SYMBOL_EXPERIMENTAL ON}
      Warnung: Symbol '<Element>' ist experimentell
      Das Symbol ist (mit der Hinweisdirektive experiamental) als experiamentell gekennzeichnet und wird (noch) nicht offizell unterstützt. Verwende möglichst ein anderes Symbol in Deinem Quelltext.
    • {$WARN UNIT_EXPERIMENTAL ON}
      Warnung: Unit '<Element>' ist experimentell
      Die Unit ist (mit der Hinweisdirektive experiamental) als experiamentell gekennzeichnet und wird (noch) nicht offizell unterstützt. Verwende möglichst ein anderes Symbol in Deinem Quelltext.
    • {$WARN OPTION_TRUNCATED ON}
      Warning: ???
      Nichts in der Hilfe gefunden
    • {$WARN WIDECHAR_REDUCED ON}
      Warning: In Set-Ausdruck WideChar auf Byte-Char verringert
      "Set of char" definiert in Win32 ein Set über den gesamten Bereich des Char-Typs. Da Char in Win32 ein byte-großer Typ ist, wird dadurch ein Set von maximaler Größe mit 256 Elementen definiert. In .NET ist Char ein wortgroßer Typ, dessen Bereich (0..65535) die Kapazität des Set-Typs überschreitet.
      Bei vorhandenem Code, der die Syntax "Set of Char" verwendet, behandelt der Compiler den Ausdruck als "set of AnsiChar". Die Warnmeldung erinnert Dich daran, dass das Set nur den Booleschen Status von 256 verschiedenen Elementen, aber nicht den vollen Bereich des Char-Typs speichern kann.
    • {$WARN DUPLICATES_IGNORED ON}
      Warning: Doppelte Symbolnamen im Namespace. '<Element>.<Element>' in <Element> gefunden. Duplikat in <Element> wird ignoriert
      Für diese Fehler- oder Warnmeldung stehen keine weiteren Informationen zur Verfügung.
    • {$WARN UNIT_INIT_SEQ ON}
      Warning: System.Runtime.CompilerServices.RunClassConstructo r nicht gefunden. Unit-Initialisierungsreihenfolge entspricht nicht der Reihenfolge in der uses-Klausel
      Diese Warnung weist darauf hin, dass die in Delphi definierte Initialisierungsreihenfolge, die durch die Reihenfolge der Units in der uses-Klausel festgelegt ist, nicht garantiert ist.
      Mit der Funktion RunClassConstructor werden die initialization-Abschnitte der Units, die von der aktuellen Unit verwendet werden, in der Reihenfolge ausgeführt, die in der uses-Klausel der aktuellen Unit festgelegt ist. Diese Warnung wird ausgegeben, wenn der Compiler diese Funktion in dem .NET-Framework finden kann. Wenn Du z.B, mit dem .NET Compact Framework linkst, das RunClassConstructor nicht implementiert, tritt diese Warnung auf.
    • {$WARN LOCAL_PINVOKE ON}
      Warning: Lokaler PInvoke-Quelltext wurde nicht erstellt, weil die externe Routine '<Element>' im Package '<Element>' mit package-lokalen Typen in den benutzerdefinierten Attributen definiert wurde
      Diese Warnung kann ausgelöst werden, wenn ein externes Package mit PInvoke auf Win32-Bibliotheksquelltext zugreift, und dieses Package die PInvoke-Definition über einen public-Export bereitstellt. In diesen Fällen versucht der Compiler, eine direkte Verknüpfung zu der Win32-Bibliothek durch Kopieren der PInvoke-Definition in die lokale Assemblierung herzustellen, anstatt mit dem public-Export in dem externen Package zu verknüpfen. Dies ist sicherer und kann auch die Laufzeitperformanz verbessern.
      Diese Warnmeldung wird ausgegeben, wenn der Compiler die PInvoke-Definition nicht lokal erstellen kann, weil die externe Assemblierung lokal definierte Typen für benutzerdefinierte Attribute verwendet. Um diese Warnung zu vermeiden, mußt Du das Package so ändern, dass keine lokal definierten Typen für benutzerdefinierte Attribute in exportierten Funktionen oder Prozeduren verwendet werden.
    • {$WARN MESSAGE_DIRECTIVE ON}
      Warning: ???
      Nichts in der Hilfe gefunden
    • {$WARN TYPEINFO_IMPLICITLY_ADDED ON}
      Warning: PUBLISHED verursachte, dass RTTI ($M+) zu Typ '<Element>' hinzugefügt wurde
      Du hast einen 'PUBLISHED'-Abschnitt zu einer Klasse hinzugefügt, die nicht mit der Option {$M+}/{$TYPEINFO ON} compiliert wurde, oder ohne Ableitung von einer Klasse, die mit der Option {$M+}/{$TYPEINFO ON} compiliert wurde.
      Die Standardprozedur TypeInfo erwartet einen Typbezeichner als Parameter. Im obigen Beispiel stellt NotType keinen Typbezeichner dar.
      Um diesen Fehler zu vermeiden, stelle sicher, dass Du nur mit der Option {$M+}/{$TYPEINFO ON} compilierst, oder von einer Klasse ableitest, die mit der Option {$M+}/{$TYPEINFO ON} compiliert wurde.
    • {$WARN XML_WHITESPACE_NOT_ALLOWED ON}
      Warning: XML-Kommentar in '<Element>' ist falsch strukturiert -- 'Whitespace ist an dieser Position nicht zulässig.'
      Diese Warnung wird ausgegeben, wenn der Compiler einen Whitespace an einer Position entdeckt, an der Whitespaces nicht zulässig sind.
      Dies ist ein Fehler bei der XML-Dokumentationsverarbeitung. Das XML ist nicht wohlgeformt. Dies ist eine Warnung, weil der Build-Prozess durch einen Dokumentationsfehler nicht verhindert wird.
    • {$WARN XML_UNKNOWN_ENTITY ON}
      Warning: XML-Kommentar in '<Element>' ist falsch strukturiert -- 'Referenz auf nicht definierte Entität '<Element>'.'
      Diese Warnung wird ausgegeben, wenn das XML eine nicht definierte Entität referenziert.
      Dies ist ein Fehler bei der XML-Dokumentationsverarbeitung. Das XML ist nicht wohlgeformt. Dies ist eine Warnung, weil der Build-Prozess durch einen Dokumentationsfehler nicht verhindert wird.
    • {$WARN XML_INVALID_NAME_START ON}
      Warning: XML-Kommentar in '<Element>' ist falsch strukturiert -- 'Ein Name beginnt mit einem ungültigen Zeichen.'
      Diese Warnung wird ausgegeben, wenn ein XML-Name mit einem ungültigen Zeichen beginnt.
      Dies ist ein Fehler bei der XML-Dokumentationsverarbeitung. Das XML ist nicht wohlgeformt. Dies ist eine Warnung, weil der Build-Prozess durch einen Dokumentationsfehler nicht verhindert wird.
    • {$WARN XML_INVALID_NAME ON}
      Warning: XML-Kommentar in '<Element>' ist falsch strukturiert -- 'Ein Name enthält ein ungültiges Zeichen.'
      Diese Warnung wird ausgegeben, wenn ein Name im XML ein ungültiges Zeichen enthält.
      Dies ist ein Fehler bei der XML-Dokumentationsverarbeitung. Das XML ist nicht wohlgeformt. Dies ist eine Warnung, weil der Build-Prozess durch einen Dokumentationsfehler nicht verhindert wird.
    • {$WARN XML_EXPECTED_CHARACTER ON}
      Warning: XML-Kommentar in '<Element>' ist falsch strukturiert -- 'Das Zeichen '<Zeichen>' wurde erwartet.'
      Diese Warnung wird ausgegeben, wenn das erwartete Zeichen im XML nicht gefunden wird.
      Dies ist ein Fehler bei der XML-Dokumentationsverarbeitung. Das XML ist nicht wohlgeformt. Dies ist eine Warnung, weil der Build-Prozess durch einen Dokumentationsfehler nicht verhindert wird.
    • {$WARN XML_CREF_NO_RESOLVE ON}
      Warning: XML-Kommentar bei '<Element>' hat das cref-Attribut '<Element>', das nicht aufgelöst werden konnte
      Diese Warnung wird ausgegeben, wenn das Attribut cref im XML nicht aufgelöst werden kann.
      Dies ist eine Warnung bei der Verarbeitung der XML-Dokumentation. Das XML ist wohlgeformt, aber die Bedeutung des Kommentars ist unsicher. XML cref-Referenzen folgen dem .NET-Stil. Details findest Du unter http://msdn2.microsoft.com/en-us/library/acd0tfbe.aspx. Der Build-Prozess wird durch eine Dokumentationswarnung nicht verhindert.
    • {$WARN XML_NO_PARM ON}
      Warning: XML-Kommentar bei '<Element>' hat ein param-Tag für '<Element>', aber es gibt keinen Parameter mit diesem Namen
      Diese Warnung wird ausgegeben, wenn das XML ein Parameter-Tag für einen nicht vorhandenen Parameter enthält.
      Dies ist eine Warnung bei der Verarbeitung der XML-Dokumentation. Das XML ist wohlgeformt, aber es wurde ein Tag für einen Parameter erstellt, der in einer Methode nicht vorhanden ist. Der Build-Prozess wird durch eine Dokumentationswarnung nicht verhindert.
    • {$WARN XML_NO_MATCHING_PARM ON}
      Warning: Parameter '<Element>' hat kein zugehöriges param-Tag im XML-Kommentar für '<Element>' (aber andere Parameter haben dieses Tag)
      Diese Warnung wird ausgegeben, wenn ein XML-Parameter im XML-Kommentar im Gegensatz zu anderen Parametern über kein zugehöriges param-Tag verfügt.
      Dies ist eine Warnung bei der Verarbeitung der XML-Dokumentation. Es ist mindestens ein Tag vorhanden, aber einige Parameter in der Methode haben kein Tag. Der Build-Prozess wird durch eine Dokumentationswarnung nicht verhindert.
  9. Wie kann ich meine Symbole oder Units als veraltet, bibliotheksspezifisch, platformabhängig oder experimentell kennzeichen?
    Es gibt 8 Compilerschalter um Warnungen auszugeben wenn der Quelltext veraltet, bibliotheksspezifisch, platformabhängig oder experimentell ist.
    (SYMBOL_DEPRECATED, SYMBOL_EXPERIMENTAL, SYMBOL_LIBRARY, SYMBOL_PLATFORM, UNIT_DEPRECATED, UNIT_EXPERIMENTAL, UNIT_LIBRARY, UNIT_PLATFORM)
    Wie kennzeichne ich meinen Code als z.B. veraltet?

    Bei Units ist das ganz einfach. Es wird einfach eins (oder mehrere) der Schlüsselwörter depecated, library, platform oder experimental hinter den Unitnamen geschrieben.
    Beisp:
    Delphi-Quellcode:
    unit Unit2 deprecated;
    // Unit2 ist veraltet und wird nicht mehr supportet. Bitte die neue Alternative Unit3 verwenden.
    ...
    oder
    Delphi-Quellcode:
    unit Unit2 deprecated platform;
    // Unit2 ist veraltet und platformzpezifisch und wird nicht mehr supportet. Bitte die neue Alternative Unit3 verwenden. Diese läuft auch unter Linux und dotNet.
    ...
    Bei den Symbolen ist es eigentlich genauso. Es wird nur bei Methoden, Funktionen und Prozeduren nach den ; geschrieben bei Konstanten, Varablen, Objekten, ... davor.
    Beisp:
    Delphi-Quellcode:
    ...
    const
      pi_alt = 3.14 deprecated;
    ...
    type
      TmyObject = class(TObject)
      public
        // nur s_alt ist veraltet
        s_alt: string deprecated;
      end;
    ...
    type
      // komplettes Objekt ist veraltet
      TmyObject_alt = class(TObject)
      public
        s_alt: string;
      end deprecated;
    ...
    procedure machWasPlatformSpezifisches_alt(s: string); deprecated platform;
    function machWasExperimentelles(s:string):string; experimental;
    ...
So ich hoffe diese Liste bringt Euch weiter
Viel Spaß
Euer MaBuSE
(°¿°) MaBuSE - proud to be a DP member
(°¿°) MaBuSE - proud to be a "Rüsselmops" ;-)
 
Benutzerbild von MaBuSE
MaBuSE

 
Delphi 10 Seattle Enterprise
 
#11
  Alt 2. Aug 2007, 18:38
Hallo Leute,
ich habe das Tutorial noch mal überarbeitet und ergänzt. (1. Beitrag)

Ich denke so wird es bleiben.

Viel Spaß
beim Lesen
  Mit Zitat antworten Zitat
Benutzerbild von MaBuSE
MaBuSE

 
Delphi 10 Seattle Enterprise
 
#12
  Alt 2. Aug 2007, 19:01
Mist die 24h zum Editieren sind um

Zitat von MaBuSE:
Oft sieht man auch folgendes:
Delphi-Quellcode:
...
procedure test;
var
  o: TObject;
begin
  try
    o := TObject.Create;
    machWasMit(o);
  finally
    o.Free;
  end;
end;
...
Hier gibt der Delphi Compiler auch eine Warnung bei der o.Free Zeile aus: Variable 'o' ist möglicherweise nicht initialisiert worden.
Das ist genau das Gleiche.
So soll try finally nicht verwendet werden! Das macht keinen Sinn. Falls in "TObject.Create;" oder "MachWasMit(o);" ein Fehler auftritt, fängt try...finally die Exception, und springt in den finally Block. Es werden nun die Befehle zwischen finally und end ausgeführt. Beim Erreichen des end; wird dann die gefangene Exception ausgelöst. Und die Prozedur bricht an der Stelle ab.
Richtig ist folgendes Beispiel (gleiches Verhalten, aber keine Warnung).
Delphi-Quellcode:
...
procedure test;
var
  o: TObject;
begin
  o := Tobject.Create;
  try
    machWasMit(o);
  finally
    o.Free;
  end;
end;
...
Das kann man auch noch mal im Exceptional exceptions im Developer Network von CodeGear nachlesen.
Ich wollte zu diesem Thema noch einen Link angeben, in dem das noch mal beschrieben wird.
(Ich musste erst nochmal meine Bookmarks duchsuchen)

Es ist der Blog von Allen Bauer. Er schrieb am 03.11.2006 einen interesannten Artikel zu genau diesem Thema:
http://blogs.codegear.com/abauer/arc.../03/28916.aspx

Viel Spaß beim Lesen.
  Mit Zitat antworten Zitat
Benutzerbild von MaBuSE
MaBuSE

 
Delphi 10 Seattle Enterprise
 
#13
  Alt 19. Sep 2008, 13:46
Zitat von MaBuSE:
Tutorial
Warnungen und Hinweise vom Delphi Compiler
Als Ergänzung zu oben genannten Tutorial gibt es hier eine *.csv Datei (lässt sich mit Excel als Tabelle öffnen) mit allen vom Delphi 2007 für Win32 unterstützten Compilermeldungen.

Es gibt 5 unterschiedliche Gruppen, die 4 aus dem Tutorial oben und eine weitere:
  • E = Error -> Fehler
    F = Fatal -> Fehler, die zu einem sofortigen Abbruch führen
    H = Hint -> Hinweis
    W = Warning -> Warnung

    und

    x = Diese Meldung wird mehrfach verwendet.
z.B. 1054 ist die benutzerdefinierte Meldung (s.o.)

Man kann mit {$message warn 'Test'} eine W1054 mit dem Text "Test" erstellen.
Mit {$message hint 'Test'} wird eine H1054 erstellt.

Die Meldungen sind string in der Format-Funktion gültigen Schreibweise abgespeichert (also mit Platzhaltern z.B. %s).

Die Meldung x1054 ist z.B. nur als "%s" definiert, da ja dort ausschließlich der Text in der $message Anweisung ausgegeben wird.
Angehängte Dateien
Dateityp: zip compilermeldungen_d2007_505.zip (21,4 KB, 27x aufgerufen)
  Mit Zitat antworten Zitat
Benutzerbild von x000x
x000x

 
Delphi XE2 Professional
 
#14
  Alt 27. Jun 2013, 12:21
Hallo MaBuSE,

super hilfreiches Tutorial - danke dafür.

Kennt jemand eine einfache Möglichkeit, nur die Warnungen/Hinweise die von externen Komponenten stammen, abzuschalten?

Hintergrund: Wir haben hier ein großes Projekt in dem wir auch viele Fremdkomponenten verwenden (QuickReport, TMS usw.). Problem ist nun, dass diese so zahlreiche Warnungen/Hinweise erzeugen, dass es nach dem Kompilieren schwer wird, Warnungen / Hinweise aus unserem Quelltext zu erkennen.
Peter
  Mit Zitat antworten Zitat
jbg

 
Delphi 10.1 Berlin Professional
 
#15
  Alt 27. Jun 2013, 12:41
Kennt jemand eine einfache Möglichkeit, nur die Warnungen/Hinweise die von externen Komponenten stammen, abzuschalten?
Vorkompilieren und im eigenen Projekt nur noch den Pfad mit den DCU Dateien in den Bibliothekspfad (SearchPath) und die Quellcodedateien in den Suchpfad (BrowsingPath) eintragen.
Andreas aka AHUser aka jbg
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:06 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz