摘自肯图的书
Constant parameters
While it works as expected for most types, for class and dynamic array parameters, const doesn’t actually prevent the
source object or array from being modified:
uses System.SysUtils;
procedure NotSoConst(const Arr: TArray<string>;
const Obj: TStringBuilder);
begin
Arr[0] := 'Er, what''s up with this?';
Obj.Append('Funny sort of "const"!');
end;
The reason for this behaviour is that classes and dynamic arrays are pure reference types. Because of that, using const
only prevents you from from changing the reference, not the data it points to. You might then expect strings to exhibit
similar behaviour, given they are reference types too. However, the compiler implements quasi-value type semantics for
strings:
type
TMyStaticArray = array[0..4] of string;
TMyRec = record
X, Y: Integer;
end;
procedure MuchBetter(const Arr: TMyStaticArray;const R: TMyRec; const S: string; const V: Variant);
begin
Arr[0] := 'Won''t compile';
R.X := 100; //won't compile
S[1] := '!'; //won't compile
S := 'Won''t compile either';
V := 'Nor will this';
end;
While amongst the reference types const only makes strings actually constant, it is still a good idea to use, assuming the
routine isn’t intending to change the values passed. In the case of dynamic arrays and other managed types, it relieves
the compiler from having to increment the argument’s reference count on entry and decrement it on exit; and for value
types whose instances are more than a few bytes, const will cause the compiler to pass internally just a pointer to the
source data rather than a copy of it, which is more efficient.
我记得论坛有一次这方面的热烈讨论