Also, wenn man mit Pointer rumpfuscht, anstatt PWideChar zu benutzen ... wenn irgendwann der Typ nicht mehr stimmt, dann beschwere dich bitte nicht, wenn der Compiler dir nichts sagen wird.
Ich dachte, es wäre klar gewesen (vor allem durch Angabe der Quelltextdatei), dass diese Funktion exakt so in den Sourcen von FPC steht. Deswegen auch meine Frage, warum die Funktion so aussieht.
Zitat:
Jemand hat vergessen zu sagen in welcher Zeile.
Ich rate mal.
Die Letzte? (mit dem Result:=)
Es gibt in dieser Funktion nur eine Zeile, wo ein UnicodeString an einen String zugewiesen wird - die Zuweisung an Result.
Zitat:
Und nun überleg mal was du dort machst.
Ich hab den Code nicht geschrieben, er ist 1:1 aus den Sourcen von FPC übernommen. Die Frage war, warum das dort so steht und ob die Warnung (bzgl. möglichem Datenverlust wegen UnicodeString -> String), die bei Übernahme der Funktion in eine eigene
Unit auftaucht, gerechtfertigt ist.
Es sei noch ergänzt, dass ich die Funktion nur aus Neugier und Verwunderung ins eigene Projekt kopiert habe. Beim Lesen der Funktion tauchten sofort die Fragen auf, warum Pointer statt PWideChar benutzt wird und warum ohne Cast/Konvertierung ein UnicodeString an String zugewiesen wird. Ich wollte herausfinden, ob bzgl. des (
Unicode)Strings eine Warnung auftaucht oder nicht. Sie taucht auf, und nun würde ich gern wissen, ob die berechtigt ist oder nicht.
Zitat:
Im Delphi war String früher AnsiString und GetModuleFileName ein Alias für GetModuleFileNameA, bzw. PChar ein PAnsiChar,
und nun ist String ein UnicodeString und GetModuleFileName ein Alias für GetModuleFileNameW mit PWideChar.
Das ist mir alles bekannt. Hier im Thread geht's aber explizit um Free Pascal.
Zitat:
Eventuell gibt es sowas mit dem genannten {$ModeSwitch UnicodeStrings}
auch für Lazarus?
Das hatte ich ja am Anfang probiert, zwar mit
{$Mode DelphiUnicode}
, aber das Ergebnis ist dasselbe wie mit
{$ModeSwitch UnicodeStrings}
. Dabei hab ich festgestellt, dass die Funktionen/Klassen aus der FPC
RTL eben nicht alle mit UnicodeString verfügbar sind. Das ist ja der Grund für den Thread hier und meine Fragen.
Zitat:
Delphi-Quellcode:
Result := Buffer;
Result := String(Buffer);
Mit Cast oder implitzt kommt erstmal das Gleiche bei raus, also vom Inhalt ... nur das Letzteres eben keine Cast-Warnung wirft.
Dass die Warnung unterdrückt wird, ist mir klar. Die Frage ist, ob man einfach so casten kann oder ob dadurch Zeichen kaputtgehen. Die Konvertierungsfunktionen (spätestens MultiByteToWideChar/WideCharToMultiByte in der
Win32 API) existieren ja sicherlich auch nicht ohne Grund.
Zitat:
Ich weiß nicht wie Lazarus/FPC das macht.
Schade. Ich hoffe, jemand kann etwas zu diesem Punkt sagen.
Zitat:
Delphi seit 2009, hat die Codepage zusätzlich im String gespeichert und Verwendet vorzugsweise Dieses.
String ist doch seit 2009 ein UnicodeString. Inwiefern spielt dabei eine Codepage eine Rolle? Oder meinst du AnsiString?
Zitat:
Vielleicht meinen die es andersrum?
vorher irgendwo {$ModeSwitch UnicodeStrings}
und später dann mit {$IFDEF UseUTF16}
testen.
Das glaube ich nicht. In der
Unit LazUnicode kann man am Anfang Folgendes finden:
Delphi-Quellcode:
// For testing the UTF16 version.
{$IF DEFINED(FPC) and DEFINED(UseUTF16)}
{$ModeSwitch UnicodeStrings} // Sets also FPC_UNICODESTRINGS.
{$ENDIF}
{$IF DEFINED(FPC_UNICODESTRINGS) or not DEFINED(FPC)}
{$DEFINE ReallyUseUTF16} // FPC with UTF-16 or Delphi
{$ENDIF}
Und im Code dieser
Unit wird dann an bestimmten Stellen
{$IFDEF ReallyUseUTF16
benutzt.
Grüße
Dalai