Es kommt auf den Sringinhalt an.
z.B.
Delphi-Quellcode:
// Pointer(S) = nil
S := '';
// Pointer(S) = ziegt direkt auf den Datenbereich, wo '1234' im Programmcode gespeichert ist
S := '1234';
// Pointer(S) = Pointer(S2) ... wobei hier nur der Referenzzähler geändert wird
S := S2;
// neuer String wird resserviert und die gesamten Stringdaten werden da reinkopiert
// die alten Stringdaten werden freigegeben
S := S + '12';
S := S2;
UniqueString(S);
// das Selbe wie bei S := S2;
// nur daß hier noch die Stringdaten nachträglich in einen eigenen Datenbereich
// kopiert und natürlich der Refferenzzähler wieder zurückgesetzt wird
...
Du siehst daß nicht immer Daten im Speicher/
RAM liegen, oder gar an der Speicherverwaltung was geändert wird.
Demnach kann es auch mal keine Probleme geben.
Probleme tauchen nur auf wo die Speicherverwaltung, also hier speziell BorlandMM ins Spiel kommt.
Also es ist ganz einfach ... solange man getrenne Speichermanager verwendet sollta man nicht an den speicherverwaltung veränderntes über Modulgrenzen hinweg machen.
Aber wenn man weiß was intern wirklich passiert, dann kann man eventuelleinige "eigenarten" ausnutzen.
z.B. geht sowas, da hierbei der MM nicht ins Spiel kommt.
Delphi-Quellcode:
procedure dllprozedure(
const s:
String);
var s2:
string;
begin
s2 := s;
UniqueString(s2);
// Ab hier kann dan mit S2 alles gemacht werden, was man
// will, egal von wo S an diese Prozedur übergeben wurde.
// Selbst über die Grenzen der Prozedur hinaus ... solange
// der String innerhalb des Moduls (EXE/DLL) verbleibt.
...
end;
function dllprozedure(
const s:
string):
string;
begin
if s = '
123'
then
result := '
irgendwas'
else
if s = '
456'
then
result := '
nochwas'
else
result := '
keinen plan';
end;