Assoooo! Und ich dachte schon ...
Der code ist mir klar. Auch die möglicherweise begleitenden Probleme die sich durch den Anruf bei Emba ergeben könnten.
Wenn man so mit dem Speicher spielt, sollte das auch klar sein.
Da greift man auch anders an:
Delphi-Quellcode:
type
//zentral deklariert
PStrLenInt ^StrLenInt;
StrLenInt = {$IFDEF FPC}SizeInt{$ELSE}LongInt{$ENDIF};
// sollte Delphi den speicher bereich über 2/4GB wie FPC-64 jemals erweitern, würde da ein weiteres Property-Based define den richtigen Type declarieren.
// somit schaut der code so aus:
function CharCount(const S: string; C: Char): Cardinal;
var
P, PEnd: PChar;
begin
Result := 0;
P := Pointer(S);
if P = nil then Exit;
PEnd := P + PStrLenInt(NativeUInt(P) - SizeOf(StrLenInt))^;
while P < PEnd do begin
if P^ = C then
Inc(Result);
Inc(P);
end;
end;
Das gewöhnt man sich an, wenn gleicher code von D2...XE10.2 laufen soll, jedoch inline code erst seit D2005 möglich ist und jeder call 50cycles verschwended, wie mir Uwe so schön gezeigt hat.
Bedenken hin oder her, wo jedoch ist das CPU64 Problem? Oder gibt es doch keins?
Edit
PS.: 4GB sind yuch nur für den UnicodeString verfügbar, da ElementSize = 2 ist, theoretische 8GB für einen UCS4String (wenn es den gibt unter Delphi?) und nur 2GB für all SingleByte-Long-Strings.
Edit2: Selbst wenn StrRec/PStrRec definiert wären wie soll denn dann der Cast ausschauen? Du hast nur einen Speichblock mit n-Bytes. Eine cast über PStrRec müßte auch rückwärts (SizeOf(StrRec))gerechnet werden.