Difference between revisions of "@"
Jwdietrich (talk | contribs) |
(typo; replace legacy syntaxhighlight syntax; mention loc function of PXSC; unify code style; more specific link target compile-time error) |
||
| (17 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| + | {{@}} | ||
| + | |||
<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 <syntaxhighlight lang="pascal" inline>@</syntaxhighlight> returns the address of an [[Identifier|identifier]] that is associated with an address (usually a [[Variable|variable]] or [[Routine|routine]], but also a [[Label#assembler|label]]). | ||
| + | Normally, the value <syntaxhighlight lang="pascal" inline>@</syntaxhighlight> returns is an ''untyped'' [[Pointer|<syntaxhighlight lang="pascal" inline>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 [[Compiler directive|directive]] [[$typedAddress|<syntaxhighlight lang="pascal" inline>{$typedAddres on}</syntaxhighlight>]]. | ||
| + | Here is an example to demonstrate what produces with untyped pointers valid and functional code, but semantically outputs an erroneous result: | ||
| + | <syntaxhighlight lang="pascal" line highlight="12">program untypedAddressDemo(input, output, stderr); | ||
| + | procedure incrementIntByRef(const ref: PByte); | ||
| + | begin | ||
| + | inc(ref^); | ||
| + | end; | ||
| − | + | var | |
| − | + | foo: integer; | |
| − | + | begin | |
| − | + | foo := -1; | |
| − | + | incrementIntByRef(@foo); | |
| − | + | writeLn(foo); | |
| − | + | end.</syntaxhighlight> | |
| − | == | + | It was intended that <syntaxhighlight lang="pascal" inline>0</syntaxhighlight> (zero) gets printed, but the program prints <syntaxhighlight lang="pascal" inline>-256</syntaxhighlight> instead. |
| − | + | With <syntaxhighlight lang="pascal" inline>{$typedAddress on}</syntaxhighlight> compilation fails with an incompatible type error. | |
| − | + | You usually want the latter behavior ([[compile-time error]]) instead of wasting time with hours of debugging. | |
| − | * [ | + | == other remarks == |
| + | * In [[ASCII]] the character <syntaxhighlight lang="pascal" inline>@</syntaxhighlight> (AT sign): has the value <syntaxhighlight lang="pascal" inline>64</syntaxhighlight>. | ||
| + | * <abbr title="Pascal extension for scientific computing">PXSC</abbr> defines the <syntaxhighlight lang="pascal" inline>loc</syntaxhighlight> function as the address-operator. | ||
| + | == read more == | ||
| + | * [https://www.freepascal.org/docs-html/ref/refse83.html The <syntaxhighlight lang="pascal" inline>@</syntaxhighlight> operator] | ||
| + | * [https://www.freepascal.org/docs-html/prog/progsu75.html Typed address operator (<syntaxhighlight lang="pascal" inline>@</syntaxhighlight>)] | ||
| + | * [[Addr|<syntaxhighlight lang="pascal" inline>addr</syntaxhighlight>]] | ||
| − | + | {{Symbols}} | |
Revision as of 18:45, 9 July 2020
│
English (en) │
suomi (fi) │
français (fr) │
русский (ru) │
The address operator @ returns the address of an identifier that is associated with an address (usually a variable or routine, but also a label).
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 {$typedAddres on}.
Here is an example to demonstrate what produces with untyped pointers valid and functional code, but semantically outputs an erroneous result:
1program untypedAddressDemo(input, output, stderr);
2
3procedure incrementIntByRef(const ref: PByte);
4begin
5 inc(ref^);
6end;
7
8var
9 foo: integer;
10begin
11 foo := -1;
12 incrementIntByRef(@foo);
13 writeLn(foo);
14end.
It was intended that 0 (zero) gets printed, but the program prints -256 instead.
With {$typedAddress on} compilation fails with an incompatible type error.
You usually want the latter behavior (compile-time error) instead of wasting time with hours of debugging.
other remarks
- In ASCII the character
@(AT sign): has the value64. - PXSC defines the
locfunction as the address-operator.
read more
| single characters |
|
| character pairs |
|
