Wie aktuell sind die Warnhinweise des Compilers

[Harry Stahl]

[Es gibt hier keine Compiler-Kategorie, daher bei IDE]

1. Bei Erstellung einer FMX-App gibt mir der Compiler einen Warnhinweis für die Verwendung von "FileGettAttr" aus, die Verwendung sei plattformspezifisch.

Wenn man mal in System.Sysutils reinsieht, sieht man aber, dass per IFDEF nach Windows und MAC/Linus-Plattform unterschieden wird. Warum erhalte ich also diesen Hinweis?

2. Für

if s[i] in LongForbiddenChars then begin erhalte ich die Warnung "[dcc32 Warnung] hs_tools_fmx.pas(600): W1050 WideChar in Set-Ausdrücken auf ByteChar verkürzt.
Ziehen Sie die Verwendung der Funktion 'CharInSet' aus der Unit 'SysUtils' in Betracht.

(OK, stimmt, könnte Probleme bei Unicode-Pairs geben)

Bei Charinset steht:

Hinweis: Es wird empfohlen, dass - wenn möglich - die Klasse TCharacter (die Unicode-fähig ist) zur Überprüfung verwendet wird, ob ein Zeichen in eine bestimme Kategorie, wie z.B. Ziffern oder Buchstaben, fällt.

Bei TCharacter steht:

Warnung: TCharacter ist veraltet. Bitte verwenden Sie TCharHelper.

Nur wie verwende ich nun TCharHelper? Die Hilfe ist ziemlich mau

( würde gerne das hier mit TCharhelper realisieren:

Delphi-Quellcode:

function hs_GetValidFilename(const Filename: string): String;
var
  i: Integer; s: String; ch: Char;
begin
  S := FileName;

  for i:=1 to length(s) do begin
    if s[i] in LongForbiddenChars then begin
      s[i] := '_';
    end;
  end;

  Result:= s;
end;

[Der schöne Günther]

Der Compiler ist 100% deterministisch und hat immer Recht.

Der Compiler trifft auf eine Methode oder Unit mit der Direktive platform und gibt die entsprechende Warnung aus. Die IFDEF-Verschachtelung davor kann er nicht beurteilen.

Delphi-Quellcode:

program Project1;

procedure stuff(); platform;
begin
   // empty
end;

begin
   {$If Defined(MSWINDOWS)}
   stuff();
   {$EndIf}
end.

Das hier reicht schon für eine Warnung.

Ebenso ist es auch bei deinem System.SysUtils.FileGetAttr(..) :

Delphi-Quellcode:

{ FileGetAttr returns the file attributes of the file given by FileName. The
  attributes can be examined by AND-ing with the faXXXX constants defined
  above. A return value of -1 indicates that an error occurred. If the
  specified file is a symlink then the function is performed on the target file.
  If FollowLink is false then the symlink file is used. }

function FileGetAttr(const FileName: string; FollowLink: Boolean = True): Integer; platform;

Analog ist es auch bei den anderen deprecated -Warnungen: Der Compiler hat Recht. Die Delphi Runtime verwendet trotzdem munter weiterhin Funktionen die sie selbst als veraltet und "Bitte nicht mehr benutzen" markiert.

Kann man nichts machen ¯\_(ツ)_/¯

Zitat:

Nur wie verwende ich nun TCharHelper?

Das ist ein Helfer. Sagen dir class helper / record helper etwas?

[KodeZwerg]

Solange wie ein CharInSet() sich kompilieren lässt, bleibe ich bei dem, sehr easy handling.

[himitsu]

Der Witz am CharInSet, dass die Sets nie erweitert/überarbeitet/verbessert/unicodefähig gemacht wurden,
dass man der Funktion sowieso nur ein Char-Set übergibt, genau das Selbe wie beim IN,
dass CharInSet intern rein nichts anderes macht, als genau den selben Code, wie das was man durch das ersetzen sollte,
und besonders krank an dem Mistding ist, dass der Compiler durch diese schwachsinnige Kapselung in einer Funktion keine Optimierung vornehmen kann.

[Schokohase]

Zitat von Harry Stahl:

1. Bei Erstellung einer FMX-App gibt mir der Compiler einen Warnhinweis für die Verwendung von "FileGettAttr" aus, die Verwendung sei plattformspezifisch.

Wenn man mal in System.Sysutils reinsieht, sieht man aber, dass per IFDEF nach Windows und MAC/Linus-Plattform unterschieden wird. Warum erhalte ich also diesen Hinweis?

Nun System.SysUtils.FileGetAttr liefert einen Integer Wert zurück. Soweit, so bekannt.

Und dieser Wert ist abhängig von der Plattform. Wenn man sehen möchte, wie unterschiedlich, der schaut einfach mal in den Source von System.IOUtils.TFile.FileAttributesToInteger.

Will man also System.SysUtils.FileGetAttr verwenden, so muss man gewährleisten, dass der Rückgabewert immer im Kontext des aktuellen Betriebssystems ausgewertet wird. Um den Entwickler daran zu erinnern gibt es diese Warnung.

Hat man dieses dann korrekt berücksichtigt, dann kann man die Warnung für den entsprechenden Code-Teil auch unterdrücken.

[Rollo62]

Ich denke IsInArray sollte der Ersatz für CharInSet sein.
Um auf die Frage am Ende zurückzukommen, wie man es umsetzt,
so sollte es theoretisch mit 0- und 1-basierten auf allen Platformen funktionieren.

Delphi-Quellcode:

{$ZEROBASEDSTRINGS ON}   // Test 0-based

procedure TForm1.FormCreate(Sender: TObject);
var
  LongForbiddenChars: array of Widechar;
  LStr : String;
  I: Integer;
begin
    LongForbiddenChars := ['A', 'B', 'E'];
    LStr               := 'BanAnE';

    for I := Low(LStr) to High(LStr) do begin
      if LStr[I].IsInArray( LongForbiddenChars ) then begin
          LStr[I] := '_';

          //LStr.Chars[] := '_' // kann man leider nicht Verwenden, nur Lesend, dehalb Low/High 
          //                    // statt for 0 to LStr.Length-1 do             
      end;
  end;

end;

Das kompiliert bei mir ohne Warnings (zumindest unter Win32), mit und ohne 0-basiert.

Ich würde am liebsten immer mit 0-basierten Strings arbeiten, und nicht diesen Low/High Mischmasch, aber das geht leider so einfach nicht wegen s.o.
Wahrscheinlich müsste es noch einen TCharHelper mit Chars[] Setter geben

Rollo

[Harry Stahl]

Zitat von Schokohase:

Zitat von Harry Stahl:

1. Bei Erstellung einer FMX-App gibt mir der Compiler einen Warnhinweis für die Verwendung von "FileGettAttr" aus, die Verwendung sei plattformspezifisch.

Wenn man mal in System.Sysutils reinsieht, sieht man aber, dass per IFDEF nach Windows und MAC/Linus-Plattform unterschieden wird. Warum erhalte ich also diesen Hinweis?

Nun System.SysUtils.FileGetAttr liefert einen Integer Wert zurück. Soweit, so bekannt.

Und dieser Wert ist abhängig von der Plattform. Wenn man sehen möchte, wie unterschiedlich, der schaut einfach mal in den Source von System.IOUtils.TFile.FileAttributesToInteger.

Will man also System.SysUtils.FileGetAttr verwenden, so muss man gewährleisten, dass der Rückgabewert immer im Kontext des aktuellen Betriebssystems ausgewertet wird. Um den Entwickler daran zu erinnern gibt es diese Warnung.

Hat man dieses dann korrekt berücksichtigt, dann kann man die Warnung für den entsprechenden Code-Teil auch unterdrücken.

OK, tatsächlich erhält nicht jede Funktion, die einen Integer zurückliefert, die Kennzeichnung "platform", sondern anscheinend nur dann, wenn es wirlich relevant ist. Das ist gut.

Habe GetFileAttr nun mit der aus System.IOUtils ersetzt.

Bekomme aber nun einen Warnhinweis, dass TFileAttributes platformspezifisch sei. Also letztlich muss ich hier nun die Warnung ausschalten.

[Schokohase]

Zitat von Harry Stahl:

OK, tatsächlich erhält nicht jede Funktion, die einen Integer zurückliefert, die Kennzeichnung "platform", sondern anscheinend nur dann, wenn es wirlich relevant ist. Das ist gut.

Ja, das ist doch aber zu erwarten, dass dieses platform nur dort zum Einsatz kommt, wenn es relevant ist. Ein TList.Count liefert einen Integer zurück aber warum sollte das mit platform gekennzeichnet sein?

Zitat von Harry Stahl:

Habe GetFileAttr nun mit der aus System.IOUtils ersetzt und erhalte nun keinen Warnhinweis mehr.

Mit welcher denn? Etwa System.IOUtils.TFile.GetAttributes? Dort solltest du auch eine Plattform-Warnung bekommen, sobald du mit System.IOUtils.TFileAttribute hantierst.

[Harry Stahl]

Du warst schneller, als meine Änderung, die ich bezüglich des doch noch vorhandenen Warnhinweises vorgenommen habe.