Changeset a17e7b8
- Timestamp:
- Jul 7, 2016, 8:27:40 AM (8 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- 540b275
- Parents:
- 4096de0
- Location:
- doc/user
- Files:
-
- 2 edited
-
pointer2.fig (modified) (1 diff)
-
user.tex (modified) (13 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/user/pointer2.fig
r4096de0 ra17e7b8 8 8 -2 9 9 1200 2 10 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 11 1500 1950 1950 1950 1950 2250 1500 2250 1500 1950 12 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 13 1500 1500 1950 1500 1950 1800 1500 1800 1500 1500 10 14 2 1 0 1 4 7 100 -1 -1 0.000 0 0 -1 1 0 2 11 15 1 1 1.00 45.00 90.00 12 2 550 1800 1800 195016 2700 1800 1950 1950 13 17 2 1 0 1 4 7 50 -1 -1 0.000 0 0 -1 1 0 2 14 18 1 1 1.00 45.00 90.00 15 2 550 1950 1800 180019 2700 1950 1950 1800 16 20 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 17 1500 1500 1800 1500 1800 1800 1500 1800 1500 150021 2700 1950 3150 1950 3150 2250 2700 2250 2700 1950 18 22 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 19 1500 1950 1800 1950 1800 2250 1500 2250 1500 1950 20 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 21 2550 1500 2850 1500 2850 1800 2550 1800 2550 1500 22 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 23 2550 1950 2850 1950 2850 2250 2550 2250 2550 1950 23 2700 1500 3150 1500 3150 1800 2700 1800 2700 1500 24 24 2 1 0 1 4 7 100 -1 -1 0.000 0 0 -1 1 0 2 25 25 1 1 1.00 45.00 90.00 26 3 600 1800 2850 195026 3900 1800 3150 1950 27 27 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 28 3 600 1500 3900 1500 3900 1800 3600 1800 3600 150028 3900 1500 4350 1500 4350 1800 3900 1800 3900 1500 29 29 4 2 0 100 0 4 10 0.0000 2 120 270 1425 2250 104\001 30 30 4 2 0 100 0 4 10 0.0000 2 120 270 1425 1800 100\001 31 31 4 2 0 100 0 4 10 0.0000 2 90 90 1425 1625 x\001 32 32 4 2 0 100 0 4 10 0.0000 2 120 90 1425 2075 y\001 33 4 1 0 100 0 4 10 0.0000 2 120 90 1650 1700 3\00134 4 1 0 100 0 4 10 0.0000 2 120 90 1650 2150 3\00135 4 0 0 100 0 4 10 0.0000 2 120 165 1875 2150 int\00136 4 0 0 100 0 4 10 0.0000 2 120 165 1875 1700 int\00137 4 2 0 100 0 4 10 0.0000 2 120 270 2 475 2250 112\00138 4 2 0 100 0 4 10 0.0000 2 150 180 2 475 2075 p2\00139 4 2 0 100 0 4 10 0.0000 2 120 270 2475 1800 108\00140 4 2 0 100 0 4 10 0.0000 2 150 180 2475 1625 p1\00141 4 1 0 100 0 4 10 0.0000 2 120 270 2700 1700 104\00142 4 1 0 100 0 4 10 0.0000 2 120 270 2700 2150 100\00143 4 0 0 100 0 4 10 0.0000 2 120 270 2925 2150 int *\00144 4 0 0 100 0 4 10 0.0000 2 120 270 2925 1700 int *\00145 4 2 0 100 0 4 10 0.0000 2 120 270 3525 1800 116\00146 4 2 0 100 0 4 10 0.0000 2 150 180 3525 1625 p3\00147 4 1 0 100 0 4 10 0.0000 2 120 270 37501700 112\00148 4 0 0 100 0 4 10 0.0000 2 120 330 3975 1700 int **\00133 4 0 0 100 0 4 10 0.0000 2 120 165 2025 2150 int\001 34 4 0 0 100 0 4 10 0.0000 2 120 165 2025 1700 int\001 35 4 2 0 100 0 4 10 0.0000 2 120 270 2625 2250 112\001 36 4 2 0 100 0 4 10 0.0000 2 150 180 2625 2075 p2\001 37 4 2 0 100 0 4 10 0.0000 2 120 270 2625 1800 108\001 38 4 2 0 100 0 4 10 0.0000 2 150 180 2625 1625 p1\001 39 4 1 0 100 0 4 10 0.0000 2 120 90 1725 2150 3\001 40 4 1 0 100 0 4 10 0.0000 2 120 90 1725 1700 3\001 41 4 0 0 100 0 4 10 0.0000 2 120 270 3225 2150 int *\001 42 4 0 0 100 0 4 10 0.0000 2 120 270 3225 1700 int *\001 43 4 2 0 100 0 4 10 0.0000 2 120 270 3825 1800 116\001 44 4 2 0 100 0 4 10 0.0000 2 150 180 3825 1625 p3\001 45 4 1 0 100 0 4 10 0.0000 2 120 270 2925 2150 100\001 46 4 1 0 100 0 4 10 0.0000 2 120 270 2925 1700 104\001 47 4 1 0 100 0 4 10 0.0000 2 120 270 4125 1700 112\001 48 4 0 0 100 0 4 10 0.0000 2 120 330 4425 1700 int **\001 -
doc/user/user.tex
r4096de0 ra17e7b8 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Wed Jul 6 21:08:24201614 %% Update Count : 10 7013 %% Last Modified On : Thu Jul 7 08:25:37 2016 14 %% Update Count : 1099 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 525 525 Special addresses are used to denote certain states or access co-processor memory. 526 526 By convention, no variable is placed at address 0, so addresses like 0, 1, 2, 3 are often used to denote no-value or other special states. 527 Often dereferencing a special state causes a memory fault, so checking is necessary during execution.527 Often dereferencing a special state causes a \Index{memory fault}, so checking is necessary during execution. 528 528 If the programming language assigns addresses, a program's execution is \Index{sound}, i.e., all addresses are to valid memory locations. 529 529 C allows programmers to assign addresses, so there is the potential for incorrect addresses, both inside and outside of the computer address-space. … … 542 542 & 543 543 \begin{lstlisting} 544 int * constx = (int *)100544 int * ®const® x = (int *)100 545 545 *x = 3; // implicit dereference 546 int * consty = (int *)104;546 int * ®const® y = (int *)104; 547 547 *y = *x; // implicit dereference 548 548 \end{lstlisting} 549 549 \end{tabular} 550 550 \end{quote2} 551 where the right example is how the compiler logically interpreters variables.552 Since a variable name only points to one location during its lifetime, it is a \Index{immutable} pointer;551 where the right example is how the compiler logically interpreters the variables in the left example. 552 Since a variable name only points to one location during its lifetime, it is an \Index{immutable} pointer; 553 553 hence, variables ©x© and ©y© are constant pointers in the compiler interpretation. 554 554 In general, variable addresses are stored in instructions instead of loaded independently, so an instruction fetch implicitly loads a variable's address. … … 594 594 In many cases, the compiler can infer the meaning: 595 595 \begin{lstlisting} 596 p2 = p1 + x; §\C{// compiler infers *p2 = *p1 + x;}§596 p2 = p1 + x; §\C{// compiler infers *p2 = *p1 + x;}§ 597 597 \end{lstlisting} 598 598 because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation. … … 600 600 However, there are ambiguous cases, especially when \Index{pointer arithmetic} is possible, as in C: 601 601 \begin{lstlisting} 602 p1 = p2; §\C{// p1 = p2 or*p1 = *p2}§603 p1 = p1 + 1; §\C{// p1 = p1 + 1 or*p1 = *p1 + 1}§602 p1 = p2; §\C{// p1 = p2\ \ or\ \ *p1 = *p2}§ 603 p1 = p1 + 1; §\C{// p1 = p1 + 1\ \ or\ \ *p1 = *p1 + 1}§ 604 604 \end{lstlisting} 605 605 … … 607 607 In C, the default meaning for pointers is to manipulate the pointer's address and the pointed-to value is explicitly accessed by the dereference operator ©*©. 608 608 \begin{lstlisting} 609 p1 = p2; §\C{// pointer address assignment}§610 *p1 = *p1 + 1; §\C{// pointed-to value assignment / operation}§609 p1 = p2; §\C{// pointer address assignment}§ 610 *p1 = *p1 + 1; §\C{// pointed-to value assignment / operation}§ 611 611 \end{lstlisting} 612 612 which works well for situations where manipulation of addresses in the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©). … … 622 622 \end{lstlisting} 623 623 624 To switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} anddenoted by ©&©.624 To switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} denoted by ©&©. 625 625 \begin{lstlisting} 626 626 int x, y, ®&® r1, ®&® r2, ®&&® r3; 627 ®&®r1 = &x; §\C{// r1 points to x}§628 ®&®r2 = &r1; §\C{// r2 also points to x}§629 ®&®r1 = &y; §\C{// r2 also points to x}§630 ®&®r1 = &r2 + 1; §\C{// r1 points to y, pointer arithmetic}§631 ®&®r3 = ®&®&r2; §\C{// r3 points to r2}§627 ®&®r1 = &x; §\C{// r1 points to x}§ 628 ®&®r2 = &r1; §\C{// r2 also points to x}§ 629 ®&®r1 = &y; §\C{// r2 also points to x}§ 630 ®&®r1 = &r2 + 1; §\C{// r1 points to y, pointer arithmetic}§ 631 ®&®r3 = ®&®&r2; §\C{// r3 points to r2}§ 632 632 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§ 633 633 \end{lstlisting} 634 Except for auto-dereferencing by the compiler, this reference example is the same as the p ointer example.634 Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example. 635 635 Hence, a reference behaves like the variable name for the current variable it is pointing-to. 636 636 The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, e.g.: … … 642 642 ®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15); 643 643 \end{lstlisting} 644 When a reference appears beside a dereference, e.g., ©&*©, they cancel out.\footnote{644 When a reference operation appears beside a dereference operation, e.g., ©&*©, they cancel out.\footnote{ 645 645 The unary ©&© operator yields the address of its operand. 646 646 If the operand has type ``type'', the result has type ``pointer to type''. … … 648 648 Hence, assigning to a reference requires the address of the reference variable (\Index{lvalue}): 649 649 \begin{lstlisting} 650 (&®*®)r1 = &x; §\C{// (\&*) cancel out giving variable r1 not the variable pointed-to by r1}§650 (&®*®)r1 = &x; §\C{// (\&*) cancel out giving variable r1 not the variable pointed-to by r1}§ 651 651 \end{lstlisting} 652 652 Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}): 653 653 \begin{lstlisting} 654 (&®*®)r3 = &(&®*®)r2; §\C{// (\&*) cancel out giving the address of variable r2}§654 (&®*®)r3 = &(&®*®)r2; §\C{// (\&*) cancel out giving the address of variable r2}§ 655 655 \end{lstlisting} 656 656 \Index{Cancellation}\index{pointer!cancellation rule} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses. … … 658 658 int x, *p1 = &x, **p2 = &p1, ***p3 = &p2, 659 659 &r1 = &x, &&r2 = &&r1, &&&r3 = &&r2; 660 ***p3 = 3; §\C{// change x}§661 r3 = 3; §\C{// change x, ***r3}§662 **p3 = ...; §\C{// change p1}§663 &r3 = ...; §\C{// change r1, (\&*)**r3, 1 cancellation}§664 *p3 = ...; §\C{// change p2}§665 &&r3 = ...; §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§666 &&&r3 = p3; §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§660 ***p3 = 3; §\C{// change x}§ 661 r3 = 3; §\C{// change x, ***r3}§ 662 **p3 = ...; §\C{// change p1}§ 663 &r3 = ...; §\C{// change r1, (\&*)**r3, 1 cancellation}§ 664 *p3 = ...; §\C{// change p2}§ 665 &&r3 = ...; §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§ 666 &&&r3 = p3; §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§ 667 667 \end{lstlisting} 668 668 Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one. … … 674 674 Java deals with the address duality by making address assignment the default and providing a \Index{clone} mechanism to change the pointed-to value. 675 675 676 As for pointers, referencesmay have qualifiers:677 \begin{lstlisting} 678 const int cx = 5; §\C{// cannot change cx;}§679 const int & r3 = &cx; §\C{// cannot change what r3 is pointing to}§680 ®&®r3 = &cx; §\C{// can change r3}§681 r3 = 7; §\C{// error, cannot change cx}§682 int & const r4 = &x; §\C{// must be initialized, \CC reference}§683 ®&®r4 = &x; §\C{// error, cannot change r4}§684 const int & const r5 = &cx; §\C{// must be initialized, \CC reference}§685 r5 = 7; §\C{// error, cannot change cx}§686 ®&®r5 = &cx; §\C{// error, cannot change r5}§676 As for a pointer, a reference may have qualifiers: 677 \begin{lstlisting} 678 const int cx = 5; §\C{// cannot change cx;}§ 679 const int & r3 = &cx; §\C{// cannot change what r3 is pointing to}§ 680 ®&®r3 = &cx; §\C{// can change r3}§ 681 r3 = 7; §\C{// error, cannot change cx}§ 682 int & const r4 = &x; §\C{// must be initialized, \CC reference}§ 683 ®&®r4 = &x; §\C{// error, cannot change r4}§ 684 const int & const r5 = &cx; §\C{// must be initialized, \CC reference}§ 685 r5 = 7; §\C{// error, cannot change cx}§ 686 ®&®r5 = &cx; §\C{// error, cannot change r5}§ 687 687 \end{lstlisting} 688 688 Hence, for type ©& const©, there is no pointer assignment, so ©&r4 = &x© is disallowed, and \emph{the address value cannot be ©0©}. 689 in effect, the compiler is managing the addressesnot the programmer.690 691 \Index{Initialization} is different than \Index{assignment} because initialization occurs on an empty (uninitialized) storage on an object, while assignment occurs on possibleinitialized storage for an object.689 In effect, the compiler is managing the addresses fpr type ©& const© not the programmer. 690 691 \Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage for an object. 692 692 There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding. 693 For reference (like pointer) initialization, the initializing value must be an address (lvalue) not a value (rvalue).694 \begin{lstlisting} 695 int * p = &x; §\C{// both \&x and x are possible interpretations}§696 int & r = x; §\C{// x unlikely interpretation, because of auto-dereferencing}§697 \end{lstlisting} 698 Hence, the compiler implicitly inserts a reference , ©&©, before the initialization expression:699 Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference .700 \begin{lstlisting} 701 int & f( int & ri ); §\C{// reference parameter and return}§702 z = f( x ) + f( y ); §\C{// referencenot required}§693 For reference initialization (like pointer), the initializing value must be an address (lvalue) not a value (rvalue). 694 \begin{lstlisting} 695 int * p = &x; §\C{// both \&x and x are possible interpretations}§ 696 int & r = x; §\C{// x unlikely interpretation, because of auto-dereferencing}§ 697 \end{lstlisting} 698 Hence, the compiler implicitly inserts a reference operator, ©&©, before the initialization expression: 699 Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference operator. 700 \begin{lstlisting} 701 int & f( int & ri ); §\C{// reference parameter and return}§ 702 z = f( x ) + f( y ); §\C{// reference operator added not required}§ 703 703 \end{lstlisting} 704 704 Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©ri© can be locally reassigned within ©f©. 705 The return reference from ©f© is copied into a compiler generated temporary, which is logicallytreated as an initialization.705 The return reference from ©f© is copied into a compiler generated temporary, which is treated as an initialization. 706 706 707 707 When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions. 708 708 \begin{lstlisting} 709 void f( constint & cri );710 void g( constint * cri );711 f( 3 ); g( &3 );709 void f( ®const® int & cri ); 710 void g( ®const® int * cri ); 711 f( 3 ); g( &3 ); 712 712 f( x + y ); g( &(x + y) ); 713 713 \end{lstlisting} 714 714 Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter. 715 (The ©&© is necessary for the pointer parameter to make the types match, and is common for a C programmer.) 716 \CFA extends this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed to by the reference parameter, which can be changed. 715 (The ©&© is necessary for the pointer parameter to make the types match, and is common requirement for a C programmer.) 716 \CFA extends this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed to by the reference parameter and can be changed. 717 \begin{lstlisting} 718 void f( int & cri ); 719 void g( int * cri ); 720 f( 3 ); g( &3 ); §\C{// compiler implicit generates temporaries}§ 721 f( x + y ); g( &(x + y) ); §\C{// compiler implicit generates temporaries}§ 722 \end{lstlisting} 717 723 Essentially, there is an implicit rvalue to lvalue conversion in this case.\footnote{ 718 724 This conversion attempts to address the \newterm{const Hell} problem, when the innocent addition of a ©const© qualifier causes a cascade of type failures, requiring an unknown number of additional ©const© qualifiers, until it is discovered a ©const© qualifier cannot be added and all the ©const© qualifiers must be removed.} … … 722 728 \begin{lstlisting} 723 729 void f( int p ) {...} 724 void (*fp)( int ) = &f; §\C{// pointer initialization}§725 void (*fp)( int ) = f; §\C{// reference initialization}§726 (*fp)(3); §\C{// pointer invocation}§727 fp(3); §\C{// reference invocation}§730 void (*fp)( int ) = &f; §\C{// pointer initialization}§ 731 void (*fp)( int ) = f; §\C{// reference initialization}§ 732 (*fp)(3); §\C{// pointer invocation}§ 733 fp(3); §\C{// reference invocation}§ 728 734 \end{lstlisting} 729 735 A routine variable is best described by a ©const© reference: … … 731 737 const void (&fp)( int ) = f; 732 738 fp( 3 ); 733 fp = ... §\C{// change code not allowed}§734 &fp = ...; §\C{// change routine refernce allowed}§739 fp = ... §\C{// change code not allowed}§ 740 &fp = ...; §\C{// change routine reference}§ 735 741 \end{lstlisting} 736 742 because the value of the routine variable is a routine literal, i.e., the routine code is normally immutable during execution.\footnote{
Note: See TracChangeset
for help on using the changeset viewer.
