Arbeiten mit PChar

[Muetze1]

Moin!

Die Funktion kann im Worst-Case Fall doppelt so lange Zeichenketten zurück geben, also:

Delphi-Quellcode:

procedure test(Const ASrcString: String);
var DestString: string;
begin
  SetLength(DestString, 2*Length(ASrcString));
  Translate(PChar(ASrcString), PChar(DestString), false);
  // Hier noch mit SetLength() den DestString auf die zurück gegebene Anzahl von zeichen kürzen...
end;

MfG
Muetze1

[Pseudemys Nelsoni]

was genau ist ein "Worst-Case Fall" ? ich meine wieso koennen doppelt soviele zeichen zurückgegeben werden ?

[Gambit]

Zitat:

Zitat von Khabarakh

Will Gambit es nicht einfach so :gruebel: ?

Delphi-Quellcode:

procedure test;
var srcString, DestString: string;
begin
  srcString:='a';
  DestString:='bb';
  Translate(PChar(srcString), PChar(DestString), false);
end;

Nene, so wollte ich es nicht, würde auch nicht funzen...

Ich würde viel jetzt viel lieber wissen, warum die Funktion nicht das tut was sie soll...

[Luckie]

Zitat:

Zitat von Gambit

Ich würde viel jetzt viel lieber wissen, warum die Funktion nicht das tut was sie soll...

Tja gute Frage. Aber ohne die Implementierung zu kennen, wird dir das wohl auch niemand sagen können. Aber: neue Frage, neuer Thread.

[Oxmyx]

Zitat:

Zitat von Binärbaum

Man sollte den Speicher reservieren, bevor man etwas in den PChar schreibt.

Nicht, wenn man ein Stringliteral schon zur Kompilierzeit zuweise. Dann nicht. In allen anderen Fällen schon.

[Gambit]

jepp und wenn ich anstelle von translate

Delphi-Quellcode:

OemToCharBuff(Pointer(S), Pointer(S), Length(S));

benutze, wo ich's mit der Speicherreservierung genauso handhaben muss, funzt es auch. Warum TDataSet.translate nicht funzt obwohl es genau das machen soll was OemToCharBuff macht, weiß ich auch nicht...