Stringübergabe an DLL

[norwegen60]

Danke für die Rückinfo. Bei den diversen Test die ich zwischenzeitlich gemacht habe, weiß ich wieder warum ich Pointern immer aus dem Weg gegangen bin.
Bei mir hat die Umsetzung des Beispiels von Michael Puff zu unregelmässigen Exceptions geführt.
Letztlich konnte ich es auf folgendes reduzieren. Komischerweise tritt hier der Exception aber konsequent auf

Delphi-Quellcode:

procedure TForm5.Button1Click(Sender: TObject);
var
  sValue : String;
begin
  sValue := 'Nur ein Test';
  TuWas(sValue);
end;

function TForm5.DoWhat(sValue):String;
var
  pBuffer: pChar;
begin
  GetMem(pBuffer, sizeof(sValue));  // length(sValue) + 1  ändert nichts
  pBuffer := pChar(sValue);
  Result := string(pBuffer);        // Auch wenn das auskommentiert ist tritt Exception auf. So wäre es aber korrekt oder?
  FreeMem(pBuffer);                 // Creates an Access Violation
end;

Was mache ich falsch? Ich verwende Delphi XE

[DeddyH]

Die Bytegröße eines Strings ergibt sich aus Length(String) * SizeOf(Char). Unter Ansi ist das gleichbedeutend mit Length(String), unter Delphi-Unicode(UTF-16) ist das Length(String) * 2.

[Luckie]

Man beachte die Entstehungszeit meiner Codes. Damals war Unicode bei Delphi noch in weiter Ferne.

[norwegen60]

Zitat von himitsu:

WideString

Und da kann ich dann einfach auf beiden Seiten zuweisen und abholen ohne mich um Speicher zu kümmern?

Zitat von Luckie:

Man beachte die Entstehungszeit meiner Codes. Damals war Unicode bei Delphi noch in weiter Ferne.

Ja schon, aber ich habe ähnliche Beispiele immer wieder gefunden. Wie macht man es denn richtig?

Zitat von DeddyH:

Die Bytegröße eines Strings ergibt sich aus Length(String) * SizeOf(Char). Unter Ansi ist das gleichbedeutend mit Length(String), unter Delphi-Unicode(UTF-16) ist das Length(String) * 2.

Egal ob ich es mit Length(String) * SizeOf(Char) oder (Length(String)+1) * SizeOf(Char)) probiere: Der Exception bleibt

[norwegen60]

Zitat von himitsu:

WideString

Hier ein Aufruf der funktioniert.

Delphi-Quellcode:

function SetCommandW(wCommand: WideString; iPrio: Integer): WideString; stdcall; external 'uv.dll';

implementation

uses
  SysUtils;

function SetCommand(sCommand: string; iPrio: Integer): string;
// Wandelt die übergebenen String in WideString und wieder zurück
var
  wCommand,
  wResult :String;
begin
  wCommand := sCommand;
  wResult := SetCommandW(wCommand,  iPrio);
  Result := wResult
end;

Diese Lösung gefällt mir super. Ich könnte auch direktResult := SetCommandW(sCommand, iPrio); schreiben oder? Damit könnte die Zwischen-Function ganz entfallen. Auf jeden Fall meldet der Compiler bei beiden Tests keine Warnung über riskante Stringwandlungen. Und da EXE und DLL imme mit dem gleichen Kompiler erstellt werden und auf denselben PC laufen sollten auch unterschiedliche CodePages kein Thema sein.
Ist das korrekt?

Zitat von Luckie:

Man beachte die Entstehungszeit meiner Codes. Damals war Unicode bei Delphi noch in weiter Ferne.

Dieser Code funktioniert jetzt auch über pChar

Delphi-Quellcode:

function SetCommandP(pCommand, pResult: pChar; iLen, iPrio: Integer): Integer; stdcall; external 'uv.dll';

implementation

uses
  SysUtils;

function SetCommand(sCommand: string; iPrio: Integer): string;
// Wandelt die übergebenen String in pChar und wieder zurück
var
  iLen: Integer;
  pCommand, pBuffer: pChar;
  sResult : String;
begin
  pCommand := pChar(sCommand);
  // Speicher anfordern
  SetLength(sResult, SetCommandP(pCommand, nil, 0, 0));
  if Length(sResult) > 0 then
    SetCommandP(pCommand, pChar(sResult), 0, 0);
  Result := sResult;
end;

Wenn ich an Zeiger denke, bin ich immer unsicher, wann ich Speicher freigeben muss. In den Beispielen die ich fand wurde aber bei SetLength nie freigegeben. Ist in dem pChar Code alles korrekt?

Wäre froh wenn ich die Bestätigung bekäme dass beide Vorgehen ab Delphi XE korrekt sind

Danke
Gerd

[Luckie]

Zitat von norwegen60:

Zitat von Luckie:

Man beachte die Entstehungszeit meiner Codes. Damals war Unicode bei Delphi noch in weiter Ferne.

Dieser Code funktioniert jetzt auch über pChar

Ja solange man die Ansitypen explizit angibt. Nur ist String in aktuellen Delphi Versionen gleiche WideString. Hätte ich damals alles als AnsiString und AnsiChar deklariert, wäre es ohne Probleme auch unter Unicode-Delphi kompilierbar. Aber wie gesagt, damals war Unicode noch kein Thema. Soi nacgt Delphi aber aus String einen WideString und so weiter. Und dann kracht es natürlich.

[himitsu]

Fast. Delphi nutzt UnicodeString als String, seit 2009, und davor AnsiString. (das sind intern erweiterte dynamische Arrays)
Und ganz früher (bis Delphi 1) war es der ShortString. (das ist ein Record mit einem statischen Array of AnsiChar und auf Index 0 liegt das Längenbyte)

Zitat von norwegen60:

Und da kann ich dann einfach auf beiden Seiten zuweisen und abholen ohne mich um Speicher zu kümmern?

Genau.

WideString hat quasi ein SharedMemory eingebaut, da DLL und EXE beide mit der selben OleAuth32 arbeiten.

String/AnsiString/UnicodeString/UTF8String/RawByteString/usw. sind Delphi Typen und arbeiten aktuell mit FastMM (DelphiMM vor 2006).
So lange man auf der anderen Seite nur liest und keine Referenzen auf den String speichert, kann man Delphi-Strings auch ohne SharedMemory verwenden, aber das sollte man nicht machen und Delphi-Strings ausschließlich mit SharedMemory verwenden, da man auch irgendwann speichern/schreiben könnte.

String-Konstanten für Delphi-Strings sind Zeiger auf das Kompilat, wo ReferenceCount (-1) und Length hartcodiert sind.