Incompatible types beim Zusammensetzen von WideChars

[Shark99]

Kann mir bitte jemand erklären wieso dieser Code unter Delphi 7 nicht kompiliert (Incompatible types)

Delphi-Quellcode:

var s1,s2: widestring;

..

s1 := 'abc';
s2 := s1[1] + s1[2]; // fehler

Gibt es eine Alternative?

[himitsu]

Du hast vergessen die ganze Fehlermeldung zu kopieren.
Und ich wette da steht die Lösung drin. :roll:

Expliziter Typecast
oder Copy

[Shark99]

Hab ich nicht, das ist alles:

[Error] UppercaseUnit1.pas(60): Incompatible types

[himitsu]

Ohhh, ich dachte auch damals wurden schon beide Typen genannt. :oops:

Zitat:

[dcc32 Fehler] Unit6.pas(28): E2010 Inkompatible Typen: 'String' und 'WideChar'

Na dann isses ja blöd. :?

[Shark99]

Die Fehlermeldung verstehe ich trotzdem nicht.

s2 ist doch ein widestring.
s1[1] und s1[2] sind widechars.

Wieso darf ich zwei widechars nicht zu einem widestring zusammensetzen? es klappt schließlich mit chars und strings.

[himitsu]

Nicht für alle Typen sind alle Operationen gleich implementiert.

String/AnsiString ist ein LongString (intern ein aufgemotztes dynamisches Char-Array).
Der Typ "String[123]" und ShortString sind ShortString (intern ein Record).
UnicodeString (seit D2009) ist auch ein LongString.
WideString ist die Kapseltung einer WinAPI (AllocSysString usw.).

Ich hatte mal das Problem, dass für String und Variant die Reihenfolge von "OR" anders ausgewertet wird.
Beim String->Variant kam erst das OR und dann der implizite Typcast
und bei Variant->String erst der Typcast und dann das OR, was dann fröhlich knallte.

[t.roller]

Zitat:
"WideString
Der Typ WideString repräsentiert einen dynamisch zugewiesenen String mit 16-Bit-Unicode-Zeichen. In einigen Punkten entspricht er mit dem Typ AnsiString. In Win32 ist der Typ WideString kompatibel mit dem COM-Typ BSTR.

WideString ist für COM-Anwendungen geeignet. WideString verfügt aber über keinen Referenzzähler, deshalb ist UnicodeString für andere Anwendungstypen flexibler und effizienter.

Eine zuverlässige Indizierung von WideString-Multibyte-Strings ist nicht möglich, da S[i] das i-te Element (und nicht notwendigerweise das i-te Zeichen) in S repräsentiert.

Die Typen Char und PChar sind in Delphi WideChar- bzw. PWideChar-Typen."
ms-help://embarcadero.rs_xe7/rad/String-Typen_(Delphi).html

[Shark99]

Eine zuverlässige Indizierung von WideString-Multibyte-Strings ist nicht möglich, da S[i] das i-te Element (und nicht notwendigerweise das i-te Zeichen) in S repräsentiert.

Das finde ich verwirrend.

Wenn man auf WideString per s[i] zugreift ist i immer das i-te Zeichen im s (so lange korrekte UTF16-Daten im S vorliegen).

D.h. bei einem string "ab"

UTF16: $61 00 $ 62 00

ist s[2] = $62 00 und nicht 00

[uligerhardt]

Hmmm... mit D2007 kompiliert das:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils;

var
  s1, s2: WideString;
begin
  s1 := 'abc';
  s2 := s1[1] + s1[2]; // fehler
end.

In dem Thema ist Varianz drin. :mrgreen:

[himitsu]

Zitat:

Zitat von Shark99 (Beitrag 1361218)

Wenn man auf WideString per s[i] zugreift ist i immer das i-te Zeichen im s (so lange korrekte UTF16-Daten im S vorliegen).

Nein. Surrogates bestehen aus 2 Zeichen (4 Byte).
Was in den "User defined character ranges" sich versteckt, dass weiß Keiner.

Ja, in Delphi fangen Strings bei 1 an, als Kompatibilität auf den ersten Delphi-Stringtypen (ShortString),
aber da sei Crossplatform können Strings plötzlich auch mal bei 0 anfangen (standardmäßig auf Android und iOS).