Wurde die Stringbehandlung eigentlich in D2010 verbessert
oder ist da immernoch so ein Kaos?

Gegeben sei diese Funktion:

markieren

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var S: String;
begin
  {$STRINGCHECKS ON}
  S := S + 'abc';
  if Length(S) = 123 then
    if S[1] = 'X' then ;
end;

früher sah es ja in etwa mal so aus (nur halt mit Ansi-Funktionen)

zusammenfalten · markieren

Delphi-Quellcode:

{$STRINGCHECKS OFF}  // StringChecks gab's damal noch nicht, also auch OFF

Unit1.pas.29: S := S + 'abc';
00461B03 8D45FC lea eax,[ebp-$04]
00461B06 BA541B4600 mov edx,$00461b54
00461B0B E8FC3BFAFF call @UStrCat

Unit1.pas.30: if Length(S) = 123 then
00461B10 8B45FC mov eax,[ebp-$04]
00461B13 85C0 test eax,eax
00461B15 7405 jz $00461b1c
00461B17 83E804 sub eax,$04
00461B1A 8B00 mov eax,[eax]
00461B1C 83F87B cmp eax,$7b
00461B1F 7507 jnz $00461b28

Unit1.pas.31: if S[1] = 'X' then ;
00461B21 8B45FC mov eax,[ebp-$04]
00461B24 66833858 cmp word ptr [eax],$58

aber inzwischen sieht es ja standardmäßig so aus

zusammenfalten · markieren

Delphi-Quellcode:

{$STRINGCHECKS ON}  // standardmäßig steht dieser Sch*** ja auf ON

Unit1.pas.29: S := S + 'abc';
00461B03 8D45FC lea eax,[ebp-$04]
00461B06 BA881B4600 mov edx,$00461b88
00461B0B E8FC3BFAFF call @UStrCat

Unit1.pas.30: if Length(S) = 123 then
00461B10 8B45FC mov eax,[ebp-$04]
00461B13 85C0 test eax,eax
00461B15 7416 jz $00461b2d
00461B17 8BD0 mov edx,eax
00461B19 83EA0A sub edx,$0a
00461B1C 66833A02 cmp word ptr [edx],$02
00461B20 740B jz $00461b2d
00461B22 8D45FC lea eax,[ebp-$04]
00461B25 8B55FC mov edx,[ebp-$04]
00461B28 E8D732FAFF call @InternalUStrFromLStr
00461B2D 85C0 test eax,eax
00461B2F 7405 jz $00461b36
00461B31 83E804 sub eax,$04
00461B34 8B00 mov eax,[eax]
00461B36 83F87B cmp eax,$7b
00461B39 7521 jnz $00461b5c

Unit1.pas.31: if S[1] = 'X' then ;
00461B3B 8B45FC mov eax,[ebp-$04]
00461B3E 85C0 test eax,eax
00461B40 7416 jz $00461b58
00461B42 8BD0 mov edx,eax
00461B44 83EA0A sub edx,$0a
00461B47 66833A02 cmp word ptr [edx],$02
00461B4B 740B jz $00461b58
00461B4D 8D45FC lea eax,[ebp-$04]
00461B50 8B55FC mov edx,[ebp-$04]
00461B53 E8AC32FAFF call @InternalUStrFromLStr
00461B58 66833858 cmp word ptr [eax],$58

Wie sieht es denn nun unter Delphi 2010 aus (dauert noch etwas mit meiner Trial )

Wenn ich bedenke, daß ich Anfangs mir selber Funktionen geschrieben hab, um dieses Verhalten via Pointer-Casting, PWideChar-Zugriffen und direktem Auslesen der Stringstrukturen in meinem himXML zu umgehn
(immerhin bremst das bei vielen Zugriffen schon etwas extrem aus)

Nun denke ich grad drüber nach, diese eigenen Funktionen wieder der Übersichtlichkeit halber zu entfernen,
seit ich hier in der DP netter Weise auf diesen Kompilerschalter gestoßen bin.
(in der OH steht ja rein garnichts dazu)

Allerdings wäre es ja schlecht, wenn sich dieses in D2010 noch verschlechtert hat.

Das ganze funktioniert immernoch so schlecht - die in SysUtils definierten Methoden (CompareText z.B.) sind immernoch mit $STRINGCHECKS ON kompiliert wie mir das CPU Fenster verrät. Und ohne explizite Angabe von $STRINGCHECKS OFF im eigenen Code wird der ganze Kram auch immernoch genauso aufgebläht. Hab aber nicht genau geschaut, ob man das global für alle neuen Projekte ausschalten kann.

Für CompareText hab ich eh eine eigene Speed-Version,
da im Endefekt auch Delphi nur (nach diesen ganzen StringCheckSachen) die WinAPI bemüht und diese auch nicht unbegingt die Flotteste ist.

Und das mit dem global umstellen wird wohl nicht gehen, da man da doch die kompletten DCUs von Delphi neu kompilieren müßte ... sonst werden ja die Kompilerschalter sozusagen nicht übernommen.


OK, also sollte es reichen, wenn ich diese Option in meinen Dateien laß
und kann dann dennoch die eigenen Funktionen ausbauen.


Ohne dieses Stringchecking kann ich mit dem restlichen Code noch leben
und muß nicht solche Funktionen drinnen lassen

zusammenfalten · markieren

Delphi-Quellcode:

Function StrLength(Const S: UnicodeString): Integer; Inline;
  Begin
    Result := Integer(S);
    If Result <> 0 Then Result := PInteger(Integer(S) - 4)^
      {$IF not Declared(UnicodeString)} div 2 {$IFEND};
  End;

Function StrChar(Const S: UnicodeString; Index: Integer = 0): WideChar; Inline; Overload;
  Begin
    Result := PWideChar(Integer(S) + Index * 2)^;
  End;

Function StrChar(Const S: AnsiString; Index: Integer = 0): AnsiChar; Inline; Overload;
  Begin
    Result := PAnsiChar(Integer(S) + Index)^;
  End;

wo dann StrChar(S, 12) statt S[12] im Code auftaucht

Mit global meinte ich eigtl als Standard für neue Projekte - und hab gerade gesehen, das kann man einstellen in 2010.

Das Ganze ist nötig, damit die C++ler auch die RTL und VCL verwenden können. Man müsste eigentlich die gesamte RTL/VCL neu übersetzen mit OFF. Aber das geht nicht, weil Emba die Übersetzung der Bibliothenken für die IDE nicht erlaubt.

Zitat von Insider2004:

Das Ganze ist nötig, damit die C++ler auch die RTL und VCL verwenden können. Man müsste eigentlich die gesamte RTL/VCL neu übersetzen mit OFF. Aber das geht nicht, weil Emba die Übersetzung der Bibliothenken für die IDE nicht erlaubt.

Es geht schon, jedoch mußt du dir deine eigenen Packages mit den Delphi-Sourcen zusammenstellen. Die Default-Packages können nicht neu übersetzt werden (und das ist gut so, sonst hätten wir eine noch größere BPL-DLL-Hölle).

Zitat von Insider2004:

Aber das geht nicht, weil Emba die Übersetzung der Bibliothenken für die IDE nicht erlaubt.

kennst du Win-Induc.A?

nja, auch ohne ihn zu kennen, kann man die Dateien neu kompilieren,
bis auf wenige Ausnahmen (wie z.B. System.dcu und SysInit.dcu) und solange man die Sourcen zur Hand hat.

Eigentlich wäre es keine schlechte Idee mal alles neu zu kompilieren, dann wären endlich mal Fehler behoben,
wie die dit Debug-Infos kompilierten Nicht-Debug-Units

Bei Lazarus, Linux, gcc etc kann man alles bis zum kleinsten Bit selber übersetzen. Da sehe ich auch keine Hölle.

Zitat von Insider2004:

Bei Lazarus, Linux, gcc etc kann man alles bis zum kleinsten Bit selber übersetzen. Da sehe ich auch keine Hölle.

Dann freu dich wenn bei einem Kunden ein "verpatchte" VCL.BPL liegt die dein Programm läd (wenn du die BPL nicht selbst SideBySide mitlieferst) und dein Programm dann irgendwelche komische Abstürze hat. Den BPL fehlt heir ene vernünftige Versionierung. Mann hat halt den gleichen Mist gemacht wie MS zu Anfang mit ihren MFC-DLL's.

Eine System.dcu und eine SysInit.dcu kann man sich auch selber erstellen ... siehe Olly's MiniExe (oder irgendwie so)

Nur ist halt nicht alles in diesen Dateien drinnen, was die IDE uns glauben läßt.
z.B. die ganze Angelegenheit der CompilerMagic und anderer Dinge, welche eigentlich im Compiler stecken, sind virtuell in der System-Unit und einige Dinge davon sind auch als Pseudocode in der System.pas drin.
Nun läßt sich die System.pas dadurch nicht wirklich kompilieren.

Was aber nicht bedeutet, daß man keine eigene DCU nutzen kann.