Difference between revisions of "@"
(more colorful syntax highlighting) |
m (link sTypedaddress) |
||
| Line 6: | Line 6: | ||
Normally, the value <syntaxhighlight lang="pascal" enclose="none">@</syntaxhighlight> returns is an ''untyped'' [[Pointer|<syntaxhighlight lang="pascal" enclose="none">pointer</syntaxhighlight>]]. | Normally, the value <syntaxhighlight lang="pascal" enclose="none">@</syntaxhighlight> returns is an ''untyped'' [[Pointer|<syntaxhighlight lang="pascal" enclose="none">pointer</syntaxhighlight>]]. | ||
| − | If you are handling pointers a lot, and want to mitigate issues with passing references of wrong type's target, you have use the directive <syntaxhighlight lang="pascal" enclose="none">{$typedaddress on}</syntaxhighlight>. | + | If you are handling pointers a lot, and want to mitigate issues with passing references of wrong type's target, you have use the directive [[sTypedaddress|<syntaxhighlight lang="pascal" enclose="none">{$typedaddress on}</syntaxhighlight>]]. |
Here some example to demonstrate, what produces with untyped pointers valid and functional code, but semantically outputs an erroneous result: | Here some example to demonstrate, what produces with untyped pointers valid and functional code, but semantically outputs an erroneous result: | ||
Revision as of 19:10, 12 February 2018
│
English (en) │
suomi (fi) │
français (fr) │
русский (ru) │
The address operator @ returns the address of a variable, procedure or function.
Normally, the value @ returns is an untyped pointer.
If you are handling pointers a lot, and want to mitigate issues with passing references of wrong type's target, you have use the directive {$typedaddress on}.
Here some example to demonstrate, what produces with untyped pointers valid and functional code, but semantically outputs an erroneous result:
0program untypedAddressDemo(input, output, stderr);
1
2procedure incrementIntByRef(const ref: PByte);
3begin
4 inc(ref^);
5end;
6
7var
8 foo: integer;
9begin
10 foo := -1;
11 incrementIntByRef(@foo);
12 writeLn(foo);
13end.
It should print 0 (zero), but prints -256.
With {$typedaddress on} compilation fails with an incompatible type error.
You usually want the latter behavior (compile-time failure) instead of wasting time with hours of debugging.
