Difference between revisions of "@"
From Free Pascal wiki
Jump to navigationJump to searchm (😜) |
(more colorful syntax highlighting) |
||
| Line 3: | Line 3: | ||
<div style="float:left; margin: 0 25px 20px 0; padding:50px; font-size:500%; font-family: Georgia; background-color: #f9f9f9; border: 2px solid #777777;">@</div> | <div style="float:left; margin: 0 25px 20px 0; padding:50px; font-size:500%; font-family: Georgia; background-color: #f9f9f9; border: 2px solid #777777;">@</div> | ||
| − | The address operator @ returns the address of a [[Variable|variable]], [[Procedure|procedure]] or [[Function|function]]. | + | The address operator <syntaxhighlight lang="pascal" enclose="none">@</syntaxhighlight> returns the address of a [[Variable|variable]], [[Procedure|procedure]] or [[Function|function]]. |
| − | Normally, the value < | + | 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 < | + | 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>. |
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: | ||
| − | <syntaxhighlight>program | + | <syntaxhighlight lang="pascal" line start="0" highlight="12">program untypedAddressDemo(input, output, stderr); |
procedure incrementIntByRef(const ref: PByte); | procedure incrementIntByRef(const ref: PByte); | ||
| Line 23: | Line 23: | ||
writeLn(foo); | writeLn(foo); | ||
end.</syntaxhighlight> | end.</syntaxhighlight> | ||
| − | It should print < | + | It should print <syntaxhighlight lang="pascal" enclose="none">0</syntaxhighlight> (zero), but prints <syntaxhighlight lang="pascal" enclose="none">-256</syntaxhighlight>. |
| − | With < | + | With <syntaxhighlight lang="pascal" enclose="none">{$typedaddress on}</syntaxhighlight> compilation fails with an incompatible type error. |
You usually want the latter behavior (compile-time failure) instead of wasting time with hours of debugging. | You usually want the latter behavior (compile-time failure) instead of wasting time with hours of debugging. | ||
== read more == | == read more == | ||
| − | * [https://www.freepascal.org/docs-html/ref/refse83.html The < | + | * [https://www.freepascal.org/docs-html/ref/refse83.html The <syntaxhighlight lang="pascal" enclose="none">@</syntaxhighlight> operator] |
| − | * [https://www.freepascal.org/docs-html/prog/progsu75.html Typed address operator (< | + | * [https://www.freepascal.org/docs-html/prog/progsu75.html Typed address operator (<syntaxhighlight lang="pascal" enclose="none">@</syntaxhighlight>)] |
[[Category:Symbols]] | [[Category:Symbols]] | ||
Revision as of 17:46, 11 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.
