operator := (x:TypeA) y:TypeB;
这里整个子程序被实现成 function 而非 procedure，y是函数返回值，而非赋值号左边变量的引用。
假设 TypeB 变量的大小很大或赋值次数很多，那么这种实现会造成不小的效率下降，效率正常的形式是
procedure SetFrom(var y:TypeB; const x:TypeA);
同样 inc 和 dec 运算符亦有此问题。
FP 甚至有这两者的返回值与首个参数类型不相同也能编译的 bug 。准确来说，假如使用了这个运算符，且返回值不能赋值给首个参数，才会编译错误。
简而言之， OI 里拿 Pascal 的重载运算符写高精度会有一定的效率牺牲。
但用 C++ 的话问题不大，甚至可以认为对效率没有影响。
Pascal (FP?) 的这种运算符重载更像是为引用类型打造的，使用于值类型（当 size 很大）时需要谨慎。

不过，对于返回 Boolean 的关系运算符，对效率造成的影响相对较小。因为可以用 const 避免大量内存复制。
若出现高精度数的比较，则重载比较运算符是不错的选择。
在记录或数组类型的排序中，为了使代码更清晰，也可以选择重载比较运算符。

Var参显然是不行的啊。如果参数是字面量的话就直接崩了。所以必须是function形式的。
返回值类型和首个参数类型不相同显然不是bug啊。。2/3返回实数从数学上显然是合理的，真正奇葩的是C语言啊。。

被抽了……我想明白了。
属性这东西能在赋值号左边却不是左值，不能取引用。
因为支持属性，所以不能按引用赋值。

。。感觉没有问题啊（先把const和var搞明白再发表言论吧。。）
难道编Pascal语言的人傻么，，就没有优化的啊~
你自己试试效率到底降低没再来说吧。。。。

@139457820
type
BigInt=array [0..1000] of LongInt;
const
BigRadix=1000000000;
BigWidth=9;
operator := (x:LongInt) b:BigInt;
begin
//writeln(HexStr(@b));
if x>=BigRadix then
begin
b[0]:=2;
b[1]:=x mod BigRadix;
b[2]:=x div BigRadix;
end
else
begin
b[0]:=1;
b[1]:=x;
end;
end;
var
bn:BigInt;
begin
//writeln(HexStr(@bn));
bn:=1024;
end.
FPC 3.0.0 ，Win32 平台下，若去掉输出地址的注释，会看到那两个地址输出是不同的。
bn 在全局区， b 在栈，从而 b 不是 bn 的引用。
然后查看反汇编，会看到这个东西：
$00401491: mov $0x40a000,%edi
$00401496: lea -0xfa4(%e
bp
),%esi
$0040149C: mov $0xfa4,%ecx
$004014A1: rep movsb %ds:(%esi),%es:(%edi)
这就是把栈上的 b （函数返回值）逐字节复制给全局的 bn 。