Changeset 02153feb
- Timestamp:
- May 18, 2017, 11:36:51 AM (7 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- c7a3081
- Parents:
- 4203f71 (diff), ba2356b (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the(diff)
links above to see all the changes relative to each parent. - Files:
-
- 2 added
- 5 edited
- 1 moved
Legend:
- Unmodified
- Added
- Removed
-
doc/bibliography/cfa.bib
r4203f71 r02153feb 862 862 } 863 863 864 @techreport{C11, 865 type = {International Standard}, 864 @manual{C11, 866 865 keywords = {ISO/IEC C 11}, 867 866 contributer = {pabuhr@plg}, 868 key = {{ISO/IEC} 9889-2011}, 869 title = {American National Standard Information technology -- Programming Languages -- {C}}, 870 institution = {International Standard Organization}, 871 address = {http://www.iso.org}, 867 author = {C11}, 868 title = {Programming Languages -- {C} {ISO/IEC} 9889:2011}, 869 edition = {3rd}, 870 publisher = {International Standard Organization}, 871 address = {\href{https://www.iso.org/standard/57853.html}{https://\-www.iso.org/\-standard/\-57853.html}}, 872 872 year = 2012, 873 873 } … … 877 877 keywords = {ISO/IEC TS 19217:2015}, 878 878 contributer = {a3moss@uwaterloo.ca}, 879 key = {{ISO/IEC} {TS} 19217},880 879 author = {Concepts}, 881 title = {Information technology -- Programming languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Extensions for concepts },882 institution= {International Standard Organization},883 address = { http://www.iso.org},880 title = {Information technology -- Programming languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Extensions for concepts {ISO/IEC} {TS} 19217:2015}, 881 publisher = {International Standard Organization}, 882 address = {\href{https://www.iso.org/standard/64031.html}{https://\-www.iso.org/\-standard/\-64031.html}}, 884 883 year = 2015 885 884 } … … 1096 1095 keywords = {ISO/IEC Cobol 14}, 1097 1096 contributer = {pabuhr@plg}, 1098 key= {Cobol14},1099 title = {Programming Languages -- {Cobol} },1097 author = {Cobol14}, 1098 title = {Programming Languages -- {Cobol} ISO/IEC 1989:2014}, 1100 1099 edition = {2nd}, 1101 organization= {International Standard ISO/IEC 1989:2014}, 1102 publisher = {International Standard Organization}, 1103 address = {http://www.iso.org}, 1100 institution = {International Standard Organization}, 1101 address = {\href{https://www.iso.org/standard/51416.html}{https://\-www.iso.org/\-standard/\-51416.html}}, 1104 1102 year = 2014, 1105 1103 } … … 2836 2834 keywords = {ISO/IEC Fortran 08}, 2837 2835 contributer = {pabuhr@plg}, 2838 key= {Fortran08},2839 title = {Programming Languages -- {Fortran} Part 1 },2840 organization= {International Standard ISO/IEC 1989:2014},2836 author = {Fortran08}, 2837 title = {Programming Languages -- {Fortran} Part 1:Base Language ISO/IEC 1539-1:2010}, 2838 edition = {3rd}, 2841 2839 publisher = {International Standard Organization}, 2842 address = { http://www.iso.org},2840 address = {\href{https://www.iso.org/standard/50459.html}{https://\-www.iso.org/\-standard/\-50459.html}}, 2843 2841 year = 2010, 2844 2842 } … … 5359 5357 } 5360 5358 5361 @manual{ ANSI14:C++,5359 @manual{C++14, 5362 5360 keywords = {ISO/IEC C++ 14}, 5363 5361 contributer = {pabuhr@plg}, 5364 key= {C++14},5365 title = {Programming Languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} },5362 author = {C++14}, 5363 title = {Programming Languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} ISO/IEC 14882:2014}, 5366 5364 edition = {4th}, 5367 organization= {International Standard ISO/IEC 14882:2014 (E)},5368 5365 publisher = {International Standard Organization}, 5369 address = { http://www.iso.org},5366 address = {\href{https://www.iso.org/standard/64029.html}{https://\-www.iso.org/\-standard/\-64029.html}}, 5370 5367 year = 2014, 5371 5368 } … … 5706 5703 5707 5704 @manual{Ada12, 5708 keywords = {Ada}, 5709 contributer = {pabuhr@plg}, 5710 title = {Programming languages -- {Ada}}, 5705 keywords = {ISO/IEC Ada}, 5706 contributer = {pabuhr@plg}, 5707 author = {Ada12}, 5708 title = {Programming languages -- {Ada} ISO/IEC 8652:2012}, 5711 5709 edition = {3rd}, 5712 organization= {International Standard ISO/IEC 1989:2014},5713 5710 publisher = {International Standard Organization}, 5714 address = { http://www.iso.org},5711 address = {\href{https://www.iso.org/standard/61507.html}{https://\-www.iso.org/\-standard/\-61507.html}}, 5715 5712 year = 2012, 5716 5713 } -
doc/user/pointer2.fig
r4203f71 r02153feb 8 8 -2 9 9 1200 2 10 6 1125 2100 3525 2400 10 11 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 1500 2100 1950 2100 1950 2400 1500 2400 1500 2100 13 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 14 2700 2100 3150 2100 3150 2400 2700 2400 2700 2100 15 4 2 0 100 0 4 10 0.0000 2 120 270 1425 2400 104\001 16 4 2 0 100 0 4 10 0.0000 2 120 90 1425 2225 y\001 17 4 0 0 100 0 4 10 0.0000 2 120 165 2025 2300 int\001 18 4 2 0 100 0 4 10 0.0000 2 120 270 2625 2400 112\001 19 4 2 0 100 0 4 10 0.0000 2 150 180 2625 2225 p2\001 20 4 1 0 100 0 4 10 0.0000 2 120 90 1725 2300 3\001 21 4 0 0 100 0 4 10 0.0000 2 120 270 3225 2300 int *\001 22 4 1 0 100 0 4 10 0.0000 2 120 270 2925 2300 100\001 23 -6 12 24 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 13 25 1500 1500 1950 1500 1950 1800 1500 1800 1500 1500 14 26 2 1 0 1 4 7 100 -1 -1 0.000 0 0 -1 1 0 2 15 27 1 1 1.00 45.00 90.00 16 2700 1800 1950 195028 2700 1800 1950 2100 17 29 2 1 0 1 4 7 50 -1 -1 0.000 0 0 -1 1 0 2 18 30 1 1 1.00 45.00 90.00 19 2700 1950 1950 1800 20 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 21 2700 1950 3150 1950 3150 2250 2700 2250 2700 1950 31 2700 2100 1950 1800 22 32 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 23 33 2700 1500 3150 1500 3150 1800 2700 1800 2700 1500 24 34 2 1 0 1 4 7 100 -1 -1 0.000 0 0 -1 1 0 2 25 35 1 1 1.00 45.00 90.00 26 3900 1800 3150 195036 3900 1800 3150 2100 27 37 2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 28 38 3900 1500 4350 1500 4350 1800 3900 1800 3900 1500 29 4 2 0 100 0 4 10 0.0000 2 120 270 1425 2250 104\00130 39 4 2 0 100 0 4 10 0.0000 2 120 270 1425 1800 100\001 31 40 4 2 0 100 0 4 10 0.0000 2 90 90 1425 1625 x\001 32 4 2 0 100 0 4 10 0.0000 2 120 90 1425 2075 y\00133 4 0 0 100 0 4 10 0.0000 2 120 165 2025 2150 int\00134 41 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\00136 4 2 0 100 0 4 10 0.0000 2 150 180 2625 2075 p2\00137 42 4 2 0 100 0 4 10 0.0000 2 120 270 2625 1800 108\001 38 43 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\00140 44 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 *\00142 45 4 0 0 100 0 4 10 0.0000 2 120 270 3225 1700 int *\001 43 46 4 2 0 100 0 4 10 0.0000 2 120 270 3825 1800 116\001 44 47 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\00146 48 4 1 0 100 0 4 10 0.0000 2 120 270 2925 1700 104\001 47 49 4 1 0 100 0 4 10 0.0000 2 120 270 4125 1700 112\001 -
doc/user/user.tex
r4203f71 r02153feb 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Mon May 15 18:29:58201714 %% Update Count : 1 59813 %% Last Modified On : Wed May 17 22:42:11 2017 14 %% Update Count : 1685 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 94 94 \author{ 95 95 \huge \CFA Team \medskip \\ 96 \Large Peter A. Buhr, Richard Bilson, Thierry Delisle, \smallskip \\96 \Large Richard Bilson, Peter A. Buhr, Thierry Delisle, \smallskip \\ 97 97 \Large Glen Ditchfield, Rodolfo G. Esteves, Aaron Moss, Rob Schluntz 98 98 }% author … … 217 217 218 218 As stated, the goal of the \CFA project is to engineer modern language features into C in an evolutionary rather than revolutionary way. 219 \CC~\cite{ c++,ANSI14:C++} is an example of a similar project;219 \CC~\cite{C++14,C++} is an example of a similar project; 220 220 however, it largely extended the language, and did not address many existing problems.\footnote{% 221 221 Two important existing problems addressed were changing the type of character literals from ©int© to ©char© and enumerator from ©int© to the type of its enumerators.} … … 514 514 The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type. 515 515 In the following example, \R{red} is for the base type and \B{blue} is for the qualifiers. 516 The \CFA declarations move the qualifiers to the left of the base type, i.e.,move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.516 The \CFA declarations move the qualifiers to the left of the base type, \ie move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type. 517 517 \begin{quote2} 518 518 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} … … 659 659 660 660 661 \section{Pointer /Reference}661 \section{Pointer/Reference} 662 662 663 663 C provides a \newterm{pointer type}; 664 664 \CFA adds a \newterm{reference type}. 665 Both types contain an \newterm{address}, which is normally a location in memory. 666 Special addresses are used to denote certain states or access co-processor memory. 667 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. 668 Often dereferencing a special state causes a \Index{memory fault}, so checking is necessary during execution. 669 If the programming language assigns addresses, a program's execution is \Index{sound}, i.e., all addresses are to valid memory locations. 670 C allows programmers to assign addresses, so there is the potential for incorrect addresses, both inside and outside of the computer address-space. 671 672 Program variables are implicit pointers to memory locations generated by the compiler and automatically dereferenced, as in: 665 These types may be derived from a object or routine type, called the \newterm{referenced type}. 666 Objects of these types contain an \newterm{address}, which is normally a location in memory, but may also address memory-mapped registers in hardware devices. 667 An integer constant expression with the value 0, or such an expression cast to type ©void *©, is called a \newterm{null-pointer constant}.\footnote{ 668 One way to conceptualize the null pointer is that no variable is placed at this address, so the null-pointer address can be used to denote an uninitialized pointer/reference object; 669 \ie the null pointer is guaranteed to compare unequal to a pointer to any object or routine.} 670 An address is \newterm{sound}, if it points to a valid memory location in scope, \ie has not been freed. 671 Dereferencing an \newterm{unsound} address, including the null pointer, is \Index{undefined}, often resulting in a \Index{memory fault}. 672 673 A program \newterm{object} is a region of data storage in the execution environment, the contents of which can represent values. 674 In most cases, objects are located in memory at an address, and the variable name for an object is an implicit address to the object generated by the compiler and automatically dereferenced, as in: 673 675 \begin{quote2} 674 \begin{tabular}{@{}ll l@{}}676 \begin{tabular}{@{}ll@{\hspace{2em}}l@{}} 675 677 \begin{cfa} 676 678 int x; … … 691 693 \end{quote2} 692 694 where the right example is how the compiler logically interprets the variables in the left example. 693 Since a variable name only points to one location during its lifetime, it is an \Index{immutable} \Index{pointer}; 694 hence, variables ©x© and ©y© are constant pointers in the compiler interpretation. 695 In general, variable addresses are stored in instructions instead of loaded independently, so an instruction fetch implicitly loads a variable's address. 695 Since a variable name only points to one address during its lifetime, it is an \Index{immutable} \Index{pointer}; 696 hence, the implicit type of pointer variables ©x© and ©y© are constant pointers in the compiler interpretation. 697 In general, variable addresses are stored in instructions instead of loaded from memory, and hence may not occupy storage. 698 These approaches are contrasted in the following: 696 699 \begin{quote2} 697 700 \begin{tabular}{@{}l|l@{}} 701 \multicolumn{1}{c|}{explicit variable address} & \multicolumn{1}{c}{implicit variable address} \\ 702 \hline 698 703 \begin{cfa} 699 704 lda r1,100 // load address of x 700 ld r2,(r1)// load value of x705 ld r2,(r1) // load value of x 701 706 lda r3,104 // load address of y 702 st r2,(r3)// store x into y707 st r2,(r3) // store x into y 703 708 \end{cfa} 704 709 & … … 711 716 \end{tabular} 712 717 \end{quote2} 713 Finally, the immutable nature of a variable's address and the fact that there is no storage for a variable addressmeans pointer assignment\index{pointer!assignment}\index{assignment!pointer} is impossible.714 Therefore, the expression ©x = y© only has one meaning, ©*x = *y©, i.e.,manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of instruction decoding.715 716 A \Index{pointer}/\Index{reference} is a generalization of a variable name, i.e.,a mutable address that can point to more than one memory location during its lifetime.717 (Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime and may not occupy storage as the literal is embedded directly into instructions.)718 Finally, the immutable nature of a variable's address and the fact that there is no storage for the variable pointer means pointer assignment\index{pointer!assignment}\index{assignment!pointer} is impossible. 719 Therefore, the expression ©x = y© has only one meaning, ©*x = *y©, \ie manipulate values, which is why explicitly writing the dereferences is unnecessary even though it occurs implicitly as part of instruction decoding. 720 721 A \Index{pointer}/\Index{reference} object is a generalization of an object variable-name, \ie a mutable address that can point to more than one memory location during its lifetime. 722 (Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime and, like a variable name, may not occupy storage as the literal is embedded directly into instructions.) 718 723 Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg: 719 724 \begin{quote2} 720 \begin{tabular}{@{}l l@{}}725 \begin{tabular}{@{}l@{\hspace{2em}}l@{}} 721 726 \begin{cfa} 722 727 int x, y, ®*® p1, ®*® p2, ®**® p3; … … 727 732 \end{cfa} 728 733 & 729 \raisebox{-0. 45\totalheight}{\input{pointer2.pstex_t}}734 \raisebox{-0.5\totalheight}{\input{pointer2.pstex_t}} 730 735 \end{tabular} 731 736 \end{quote2} 732 737 733 738 Notice, an address has a duality\index{address!duality}: a location in memory or the value at that location. 734 In many cases, a compiler might be able to infer the meaning: 739 In many cases, a compiler might be able to infer the best meaning for these two cases. 740 For example, \Index*{Algol68}~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage 735 741 \begin{cfa} 736 742 p2 = p1 + x; §\C{// compiler infers *p2 = *p1 + x;}§ 737 743 \end{cfa} 738 because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation.739 \Index*{Algol68}~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage. 740 However, in C, the following cases are ambiguous, especially with pointer arithmetic: 741 \begin{cfa} 742 p1 = p2; §\C{// p1 = p2\ \ or\ \ *p1 = *p2}§ 743 p1 = p1 + 1; §\C{// p1 = p1 + 1\ \ or\ \ *p1 = *p1 + 1}§ 744 \end{cfa} 745 746 Most languages pick one meaning as the default and the programmer explicitly indicates the other meaning to resolve the address-duality ambiguity\index{address! ambiguity}. 747 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 ©*©. 744 Algol68 infers the following deferencing ©*p2 = *p1 + x©, because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation. 745 Unfortunately, automatic dereferencing does not work in all cases, and so some mechanism is necessary to fix incorrect choices. 746 747 Rather than dereference inferencing, most programming languages pick one implicit dereferencing semantics, and the programmer explicitly indicates the other to resolve address-duality. 748 In C, objects of pointer type always manipulate the pointer object's address: 749 \begin{cfa} 750 p1 = p2; §\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}§ 751 p2 = p1 + x; §\C{// p2 = p1 + x\ \ rather than\ \ *p1 = *p1 + x}§ 752 \end{cfa} 753 even though the assignment to ©p2© is likely incorrect, and the programmer probably meant: 748 754 \begin{cfa} 749 755 p1 = p2; §\C{// pointer address assignment}§ 750 *p1 = *p1 + 1;§\C{// pointed-to value assignment / operation}§751 \end{cfa} 752 whichworks well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).756 ®*®p2 = ®*®p1 + x; §\C{// pointed-to value assignment / operation}§ 757 \end{cfa} 758 The C semantics works well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©). 753 759 754 760 However, in most other situations, the pointed-to value is requested more often than the pointer address. … … 762 768 \end{cfa} 763 769 764 To s witch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} denoted by ©&©.770 To support this common case, a reference type is introduced in \CFA, denoted by ©&©, which is the opposite dereference semantics to a pointer type, making the value at the pointed-to location the implicit semantics for dereferencing. 765 771 \begin{cfa} 766 772 int x, y, ®&® r1, ®&® r2, ®&&® r3; … … 773 779 Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example. 774 780 Hence, a reference behaves like the variable name for the current variable it is pointing-to. 775 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, \eg: 776 \begin{cfa} 777 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); 778 \end{cfa} 779 is rewritten as: 781 One way to conceptualize a reference is via a rewrite rule, where the compiler inserts a dereference operator before the reference variable for each reference qualifier in a declaration, so the previous example becomes: 780 782 \begin{cfa} 781 783 ®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15); … … 793 795 (&(&®*®)®*®)r3 = &(&®*®)r2; §\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving variable r3}§ 794 796 \end{cfa} 795 Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses. 797 Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth. 798 799 Fundamentally, pointer and reference objects are functionally interchangeable because both contain addresses. 796 800 \begin{cfa} 797 801 int x, *p1 = &x, **p2 = &p1, ***p3 = &p2, … … 805 809 &&&r3 = p3; §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§ 806 810 \end{cfa} 807 Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one. 808 That is, all implicit dereferencing and any cancellation is carried out prior to the start of the program, so reference performance is equivalent to pointer performance. 809 A programmer selects a pointer or reference type solely on whether the address is dereferenced frequently or infrequently, which dictates the amount of direct aid from the compiler; 810 otherwise, everything else is equal. 811 812 Interestingly, \Index*[C++]{\CC} deals with the address duality by making the pointed-to value the default, and prevent\-ing changes to the reference address, which eliminates half of the duality. 813 \Index*{Java} deals with the address duality by making address assignment the default and requiring field assignment (direct or indirect via methods), i.e., there is no builtin bit-wise or method-wise assignment, which eliminates half of the duality. 814 815 As for a pointer, a reference may have qualifiers: 811 Furthermore, both types are equally performant, as the same amount of dereferencing occurs for both types. 812 Therefore, the choice between them is based solely on whether the address is dereferenced frequently or infrequently, which dictates the amount of dereferencing aid from the compiler. 813 814 As for a pointer type, a reference type may have qualifiers: 816 815 \begin{cfa} 817 816 const int cx = 5; §\C{// cannot change cx;}§ … … 819 818 ®&®cr = &cx; §\C{// can change cr}§ 820 819 cr = 7; §\C{// error, cannot change cx}§ 821 int & const rc = x; §\C{// must be initialized , \CC reference}§820 int & const rc = x; §\C{// must be initialized}§ 822 821 ®&®rc = &x; §\C{// error, cannot change rc}§ 823 const int & const crc = cx; §\C{// must be initialized , \CC reference}§822 const int & const crc = cx; §\C{// must be initialized}§ 824 823 crc = 7; §\C{// error, cannot change cx}§ 825 824 ®&®crc = &cx; §\C{// error, cannot change crc}§ 826 825 \end{cfa} 827 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}, \eg: 828 \begin{cfa} 829 int & const r = *0; §\C{// where 0 is the int * zero}§ 830 \end{cfa} 831 Otherwise, the compiler is managing the addresses for type ©& const© not the programmer, and by a programming discipline of only using references with references, address errors can be prevented. 826 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced into the reference}: 827 \begin{cfa} 828 int & const cr = *0; §\C{// where 0 is the int * zero}§ 829 \end{cfa} 830 Note, constant reference types do not prevent addressing errors because of explicit storage-management: 831 \begin{cfa} 832 int & const cr = *malloc(); 833 delete &cr; 834 cr = 7; §\C{// unsound pointer dereference}§ 835 \end{cfa} 836 832 837 Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers. 833 838 The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations; … … 849 854 where the \CFA declaration is read left-to-right (see \VRef{s:Declarations}). 850 855 856 In contract to \CFA reference types, \Index*[C++]{\CC{}}'s reference types are all ©const© references, preventing changes to the reference address, so only value assignment is possible, which eliminates half of the \Index{address duality}. 857 \Index*{Java}'s reference types to objects (because all Java objects are on the heap) are like C pointers, which always manipulate the address and there is no (bit-wise) object assignment, so objects are explicitly cloned by shallow or deep copying, which eliminates half of the address duality. 858 851 859 \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 of an object. 852 860 There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding. 853 861 For reference initialization (like pointer), the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}). 854 862 \begin{cfa} 855 int * p = &x; §\C{// both \&x and x are possible interpretations }§863 int * p = &x; §\C{// both \&x and x are possible interpretations in C}§ 856 864 int & r = x; §\C{// x unlikely interpretation, because of auto-dereferencing}§ 857 865 \end{cfa} 858 Hence, the compiler implicitly inserts a reference operator, ©&©, before the initialization expression. 859 Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference operator. 866 C allows ©p© to be assigned with ©&x© or ©x© (many compilers warn about the latter assignment). 867 \CFA allows ©r© to be assigned ©x© only because it inferences a dereference for ©x©, by implicitly inserting a address-of operator, ©&©, before the initialization expression because a reference behaves like the variable name it is pointing-to. 868 Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference operator for the same reason. 860 869 \begin{cfa} 861 870 int & f( int & rp ); §\C{// reference parameter and return}§ … … 863 872 \end{cfa} 864 873 Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©rp© can be locally reassigned within ©f©. 865 Since ©?+?© takes its arguments by value, the references returned from ©f© are used to initialize compiler generated temporaries with value semantics that copy from the references.874 Since operator routine ©?+?© takes its arguments by value, the references returned from ©f© are used to initialize compiler generated temporaries with value semantics that copy from the references. 866 875 867 876 When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions. … … 873 882 \end{cfa} 874 883 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. 875 (The ©&© is necessary for the pointer parameter to make the types match, and is a common requirement for a C programmer.)884 (The ©&© is necessary for the pointer-type parameter to make the types match, and is a common requirement for a C programmer.) 876 885 \CFA \emph{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. 877 886 \begin{cfa} … … 885 894 The implicit conversion allows seamless calls to any routine without having to explicitly name/copy the literal/expression to allow the call. 886 895 887 While \CFA attempts to handle pointers and references in a uniform, symmetric manner, C handles routine variables in an inconsistent way: a routine variableis both a pointer and a reference (particle and wave).896 While \CFA attempts to handle pointers and references in a uniform, symmetric manner, C handles routine objects in an inconsistent way: a routine object is both a pointer and a reference (particle and wave). 888 897 \begin{cfa} 889 898 void f( int p ) {...} … … 893 902 fp(3); §\C{// reference invocation}§ 894 903 \end{cfa} 895 A routine variableis best described by a ©const© reference:904 A routine object is best described by a ©const© reference: 896 905 \begin{cfa} 897 906 const void (&fp)( int ) = f; … … 900 909 &fp = ...; §\C{// changing routine reference}§ 901 910 \end{cfa} 902 because the value of the routine variable is a routine literal, i.e.,the routine code is normally immutable during execution.\footnote{911 because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{ 903 912 Dynamic code rewriting is possible but only in special circumstances.} 904 \CFA allows this additional use of references for routine variables in an attempt to give a more consistent meaning for them. 913 \CFA allows this additional use of references for routine objects in an attempt to give a more consistent meaning for them. 914 915 916 \begin{comment} 917 \section{References} 918 919 By introducing references in parameter types, users are given an easy way to pass a value by reference, without the need for NULL pointer checks. 920 In structures, a reference can replace a pointer to an object that should always have a valid value. 921 When a structure contains a reference, all of its constructors must initialize the reference and all instances of this structure must initialize it upon definition. 922 923 The syntax for using references in \CFA is the same as \CC with the exception of reference initialization. 924 Use ©&© to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields). 925 When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference. 926 The ©&© is used on both sides of the expression to clarify that the address of the reference is being set to the address of the variable to which it refers. 927 928 929 From: Richard Bilson <rcbilson@gmail.com> 930 Date: Wed, 13 Jul 2016 01:58:58 +0000 931 Subject: Re: pointers / references 932 To: "Peter A. Buhr" <pabuhr@plg2.cs.uwaterloo.ca> 933 934 As a general comment I would say that I found the section confusing, as you move back and forth 935 between various real and imagined programming languages. If it were me I would rewrite into two 936 subsections, one that specifies precisely the syntax and semantics of reference variables and 937 another that provides the rationale. 938 939 I don't see any obvious problems with the syntax or semantics so far as I understand them. It's not 940 obvious that the description you're giving is complete, but I'm sure you'll find the special cases 941 as you do the implementation. 942 943 My big gripes are mostly that you're not being as precise as you need to be in your terminology, and 944 that you say a few things that aren't actually true even though I generally know what you mean. 945 946 20 C provides a pointer type; CFA adds a reference type. Both types contain an address, which is normally a 947 21 location in memory. 948 949 An address is not a location in memory; an address refers to a location in memory. Furthermore it 950 seems weird to me to say that a type "contains" an address; rather, objects of that type do. 951 952 21 Special addresses are used to denote certain states or access co-processor memory. By 953 22 convention, no variable is placed at address 0, so addresses like 0, 1, 2, 3 are often used to denote no-value 954 23 or other special states. 955 956 This isn't standard C at all. There has to be one null pointer representation, but it doesn't have 957 to be a literal zero representation and there doesn't have to be more than one such representation. 958 959 23 Often dereferencing a special state causes a memory fault, so checking is necessary 960 24 during execution. 961 962 I don't see the connection between the two clauses here. I feel like if a bad pointer will not cause 963 a memory fault then I need to do more checking, not less. 964 965 24 If the programming language assigns addresses, a program's execution is sound, \ie all 966 25 addresses are to valid memory locations. 967 968 You haven't said what it means to "assign" an address, but if I use my intuitive understanding of 969 the term I don't see how this can be true unless you're assuming automatic storage management. 970 971 1 Program variables are implicit pointers to memory locations generated by the compiler and automatically 972 2 dereferenced, as in: 973 974 There is no reason why a variable needs to have a location in memory, and indeed in a typical 975 program many variables will not. In standard terminology an object identifier refers to data in the 976 execution environment, but not necessarily in memory. 977 978 13 A pointer/reference is a generalization of a variable name, \ie a mutable address that can point to more 979 14 than one memory location during its lifetime. 980 981 I feel like you're off the reservation here. In my world there are objects of pointer type, which 982 seem to be what you're describing here, but also pointer values, which can be stored in an object of 983 pointer type but don't necessarily have to be. For example, how would you describe the value denoted 984 by "&main" in a C program? I would call it a (function) pointer, but that doesn't satisfy your 985 definition. 986 987 16 not occupy storage as the literal is embedded directly into instructions.) Hence, a pointer occupies memory 988 17 to store its current address, and the pointer's value is loaded by dereferencing, e.g.: 989 990 As with my general objection regarding your definition of variables, there is no reason why a 991 pointer variable (object of pointer type) needs to occupy memory. 992 993 21 p2 = p1 + x; // compiler infers *p2 = *p1 + x; 994 995 What language are we in now? 996 997 24 pointer usage. However, in C, the following cases are ambiguous, especially with pointer arithmetic: 998 25 p1 = p2; // p1 = p2 or *p1 = *p2 999 1000 This isn't ambiguous. it's defined to be the first option. 1001 1002 26 p1 = p1 + 1; // p1 = p1 + 1 or *p1 = *p1 + 1 1003 1004 Again, this statement is not ambiguous. 1005 1006 13 example. Hence, a reference behaves like the variable name for the current variable it is pointing-to. The 1007 14 simplest way to understand a reference is to imagine the compiler inserting a dereference operator before 1008 15 the reference variable for each reference qualifier in a declaration, e.g.: 1009 1010 It's hard for me to understand who the audience for this part is. I think a practical programmer is 1011 likely to be satisfied with "a reference behaves like the variable name for the current variable it 1012 is pointing-to," maybe with some examples. Your "simplest way" doesn't strike me as simpler than 1013 that. It feels like you're trying to provide a more precise definition for the semantics of 1014 references, but it isn't actually precise enough to be a formal specification. If you want to 1015 express the semantics of references using rewrite rules that's a great way to do it, but lay the 1016 rules out clearly, and when you're showing an example of rewriting keep your 1017 references/pointers/values separate (right now, you use \eg "r3" to mean a reference, a pointer, 1018 and a value). 1019 1020 24 Cancellation works to arbitrary depth, and pointer and reference values are interchangeable because both 1021 25 contain addresses. 1022 1023 Except they're not interchangeable, because they have different and incompatible types. 1024 1025 40 Interestingly, C++ deals with the address duality by making the pointed-to value the default, and prevent- 1026 41 ing changes to the reference address, which eliminates half of the duality. Java deals with the address duality 1027 42 by making address assignment the default and requiring field assignment (direct or indirect via methods), 1028 43 \ie there is no builtin bit-wise or method-wise assignment, which eliminates half of the duality. 1029 1030 I can follow this but I think that's mostly because I already understand what you're trying to 1031 say. I don't think I've ever heard the term "method-wise assignment" and I don't see you defining 1032 it. Furthermore Java does have value assignment of basic (non-class) types, so your summary here 1033 feels incomplete. (If it were me I'd drop this paragraph rather than try to save it.) 1034 1035 11 Hence, for type & const, there is no pointer assignment, so &rc = &x is disallowed, and the address value 1036 12 cannot be 0 unless an arbitrary pointer is assigned to the reference. 1037 1038 Given the pains you've taken to motivate every little bit of the semantics up until now, this last 1039 clause ("the address value cannot be 0") comes out of the blue. It seems like you could have 1040 perfectly reasonable semantics that allowed the initialization of null references. 1041 1042 12 In effect, the compiler is managing the 1043 13 addresses for type & const not the programmer, and by a programming discipline of only using references 1044 14 with references, address errors can be prevented. 1045 1046 Again, is this assuming automatic storage management? 1047 1048 18 rary binding. For reference initialization (like pointer), the initializing value must be an address (lvalue) not 1049 19 a value (rvalue). 1050 1051 This sentence appears to suggest that an address and an lvalue are the same thing. 1052 1053 20 int * p = &x; // both &x and x are possible interpretations 1054 1055 Are you saying that we should be considering "x" as a possible interpretation of the initializer 1056 "&x"? It seems to me that this expression has only one legitimate interpretation in context. 1057 1058 21 int & r = x; // x unlikely interpretation, because of auto-dereferencing 1059 1060 You mean, we can initialize a reference using an integer value? Surely we would need some sort of 1061 cast to induce that interpretation, no? 1062 1063 22 Hence, the compiler implicitly inserts a reference operator, &, before the initialization expression. 1064 1065 But then the expression would have pointer type, which wouldn't be compatible with the type of r. 1066 1067 22 Similarly, 1068 23 when a reference is used for a parameter/return type, the call-site argument does not require a reference 1069 24 operator. 1070 1071 Furthermore, it would not be correct to use a reference operator. 1072 1073 45 The implicit conversion allows 1074 1 seamless calls to any routine without having to explicitly name/copy the literal/expression to allow the call. 1075 2 While C' attempts to handle pointers and references in a uniform, symmetric manner, C handles routine 1076 3 variables in an inconsistent way: a routine variable is both a pointer and a reference (particle and wave). 1077 1078 After all this talk of how expressions can have both pointer and value interpretations, you're 1079 disparaging C because it has expressions that have both pointer and value interpretations? 1080 1081 On Sat, Jul 9, 2016 at 4:18 PM Peter A. Buhr <pabuhr@plg.uwaterloo.ca> wrote: 1082 > Aaron discovered a few places where "&"s are missing and where there are too many "&", which are 1083 > corrected in the attached updated. None of the text has changed, if you have started reading 1084 > already. 1085 \end{comment} 905 1086 906 1087 … … 1353 1534 because 1354 1535 1355 Currently, there are no \Index{lambda} expressions, i.e.,unnamed routines because routine names are very important to properly select the correct routine.1356 1357 1358 \section{ Lexical List}1536 Currently, there are no \Index{lambda} expressions, \ie unnamed routines because routine names are very important to properly select the correct routine. 1537 1538 1539 \section{Tuples} 1359 1540 1360 1541 In C and \CFA, lists of elements appear in several contexts, such as the parameter list for a routine call. … … 1373 1554 [ v+w, x*y, 3.14159, f() ] 1374 1555 \end{cfa} 1375 Tuples are permitted to contain sub-tuples ( i.e.,nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple.1556 Tuples are permitted to contain sub-tuples (\ie nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple. 1376 1557 Note, a tuple is not a record (structure); 1377 1558 a record denotes a single value with substructure, whereas a tuple is multiple values with no substructure (see flattening coercion in Section 12.1). … … 1429 1610 tuple does not have structure like a record; a tuple is simply converted into a list of components. 1430 1611 \begin{rationale} 1431 The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; i.e.,a statement such as ©g( f() )© is not supported.1612 The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; \ie a statement such as ©g( f() )© is not supported. 1432 1613 Using a temporary variable to store the results of the inner routine and then passing this variable to the outer routine works, however. 1433 1614 \end{rationale} … … 1442 1623 This requirement is the same as for comma expressions in argument lists. 1443 1624 1444 Type qualifiers, i.e.,const and volatile, may modify a tuple type.1445 The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], i.e.,the qualifier is distributed across all of the types in the tuple, \eg:1625 Type qualifiers, \ie const and volatile, may modify a tuple type. 1626 The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], \ie the qualifier is distributed across all of the types in the tuple, \eg: 1446 1627 \begin{cfa} 1447 1628 const volatile [ int, float, const int ] x; … … 1481 1662 ©w© is implicitly opened to yield a tuple of four values, which are then assigned individually. 1482 1663 1483 A \newterm{flattening coercion} coerces a nested tuple, i.e.,a tuple with one or more components, which are themselves tuples, into a flattened tuple, which is a tuple whose components are not tuples, as in:1664 A \newterm{flattening coercion} coerces a nested tuple, \ie a tuple with one or more components, which are themselves tuples, into a flattened tuple, which is a tuple whose components are not tuples, as in: 1484 1665 \begin{cfa} 1485 1666 [ a, b, c, d ] = [ 1, [ 2, 3 ], 4 ]; … … 1516 1697 \end{cfa} 1517 1698 \index{lvalue} 1518 The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, i.e.,any data object that can appear on the left-hand side of a conventional assignment statement.1699 The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, \ie any data object that can appear on the left-hand side of a conventional assignment statement. 1519 1700 ©$\emph{expr}$© is any standard arithmetic expression. 1520 1701 Clearly, the types of the entities being assigned must be type compatible with the value of the expression. … … 1604 1785 [ x1, y1 ] = z = 0; 1605 1786 \end{cfa} 1606 As in C, the rightmost assignment is performed first, i.e.,assignment parses right to left.1787 As in C, the rightmost assignment is performed first, \ie assignment parses right to left. 1607 1788 1608 1789 … … 1669 1850 1670 1851 1671 \section{Labelled Continue /Break}1852 \section{Labelled Continue/Break} 1672 1853 1673 1854 While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure. … … 1766 1947 With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader. 1767 1948 Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs. 1768 The implicit targets of the current ©continue© and ©break©, i.e.,the closest enclosing loop or ©switch©, change as certain constructs are added or removed.1949 The implicit targets of the current ©continue© and ©break©, \ie the closest enclosing loop or ©switch©, change as certain constructs are added or removed. 1769 1950 1770 1951 … … 1903 2084 Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic. 1904 2085 As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized. 1905 The key observation is that the ©switch© statement branches into control structure, i.e.,there are multiple entry points into its statement body.2086 The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body. 1906 2087 \end{enumerate} 1907 2088 … … 1911 2092 the number of ©switch© statements is small, 1912 2093 \item 1913 most ©switch© statements are well formed ( i.e.,no \Index*{Duff's device}),2094 most ©switch© statements are well formed (\ie no \Index*{Duff's device}), 1914 2095 \item 1915 2096 the ©default© clause is usually written as the last case-clause, … … 1921 2102 \item 1922 2103 Eliminating default fall-through has the greatest potential for affecting existing code. 1923 However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, i.e.,a list of ©case© clauses executing common code, \eg:2104 However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, \ie a list of ©case© clauses executing common code, \eg: 1924 2105 \begin{cfa} 1925 2106 case 1: case 2: case 3: ... … … 2173 2354 2174 2355 The following \CC-style \Index{manipulator}s allow control over implicit seperation. 2175 Manipulators \Indexc{sepOn}\index{manipulator!sepOn@©sepOn©} and \Indexc{sepOff}\index{manipulator!sepOff@©sepOff©} \emph{locally} toggle printing the separator, i.e.,the seperator is adjusted only with respect to the next printed item.2356 Manipulators \Indexc{sepOn}\index{manipulator!sepOn@©sepOn©} and \Indexc{sepOff}\index{manipulator!sepOff@©sepOff©} \emph{locally} toggle printing the separator, \ie the seperator is adjusted only with respect to the next printed item. 2176 2357 \begin{cfa}[mathescape=off,belowskip=0pt] 2177 2358 sout | sepOn | 1 | 2 | 3 | sepOn | endl; §\C{// separator at start of line}§ … … 2186 2367 12 3 2187 2368 \end{cfa} 2188 Manipulators \Indexc{sepDisable}\index{manipulator!sepDisable@©sepDisable©} and \Indexc{sepEnable}\index{manipulator!sepEnable@©sepEnable©} \emph{globally} toggle printing the separator, i.e.,the seperator is adjusted with respect to all subsequent printed items, unless locally adjusted.2369 Manipulators \Indexc{sepDisable}\index{manipulator!sepDisable@©sepDisable©} and \Indexc{sepEnable}\index{manipulator!sepEnable@©sepEnable©} \emph{globally} toggle printing the separator, \ie the seperator is adjusted with respect to all subsequent printed items, unless locally adjusted. 2189 2370 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] 2190 2371 sout | sepDisable | 1 | 2 | 3 | endl; §\C{// globally turn off implicit separation}§ … … 2461 2642 \caption{Constructors and Destructors} 2462 2643 \end{figure} 2463 2464 2465 \begin{comment}2466 \section{References}2467 2468 2469 By introducing references in parameter types, users are given an easy way to pass a value by reference, without the need for NULL pointer checks.2470 In structures, a reference can replace a pointer to an object that should always have a valid value.2471 When a structure contains a reference, all of its constructors must initialize the reference and all instances of this structure must initialize it upon definition.2472 2473 The syntax for using references in \CFA is the same as \CC with the exception of reference initialization.2474 Use ©&© to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).2475 When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference.2476 The ©&© is used on both sides of the expression to clarify that the address of the reference is being set to the address of the variable to which it refers.2477 \end{comment}2478 2644 2479 2645 … … 4683 4849 \section{Incompatible} 4684 4850 4685 The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{ ANSI14:C++}.4851 The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{C++14}. 4686 4852 4687 4853 \begin{enumerate} … … 4781 4947 Personß.ßFace pretty; §\C{// type defined inside}§ 4782 4948 \end{cfa} 4783 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, i.e.,the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing.4949 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, \ie the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing. 4784 4950 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}. 4785 4951 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''. … … 4878 5044 \end{tabular} 4879 5045 \end{quote2} 4880 For the prescribed head-files, \CFA implicitly wraps theirincludes in an ©extern "C"©;5046 For the prescribed head-files, \CFA uses header interposition to wraps these includes in an ©extern "C"©; 4881 5047 hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}). 4882 5048 All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling. … … 4886 5052 \label{s:StandardLibrary} 4887 5053 4888 The goal of the \CFA standard-library is to wrap many of the existing C library-routines that are explicitly polymorphic into implicitlypolymorphic versions.5054 The \CFA standard-library wraps many existing explicitly-polymorphic C general-routines into implicitly-polymorphic versions. 4889 5055 4890 5056 … … 5010 5176 \label{s:Math Library} 5011 5177 5012 The goal of the \CFA math-library is to wrap many of the existing C math library-routines that are explicitly polymorphic into implicitlypolymorphic versions.5178 The \CFA math-library wraps many existing explicitly-polymorphic C math-routines into implicitly-polymorphic versions. 5013 5179 5014 5180 -
src/Parser/ExpressionNode.cc
r4203f71 r02153feb 10 10 // Created On : Sat May 16 13:17:07 2015 11 11 // Last Modified By : Peter A. Buhr 12 // Last Modified On : Thu Mar 30 17:02:46201713 // Update Count : 5 1512 // Last Modified On : Wed May 17 21:31:01 2017 13 // Update Count : 527 14 14 // 15 15 … … 207 207 } // build_field_name_fraction_constants 208 208 209 210 209 211 Expression * build_field_name_REALFRACTIONconstant( const std::string & str ) { 210 assert( str[0] == '.');212 if ( str.find_first_not_of( "0123456789", 1 ) != string::npos ) throw SemanticError( "invalid tuple index " + str ); 211 213 Expression * ret = build_constantInteger( *new std::string( str.substr(1) ) ); 212 214 delete &str; … … 215 217 216 218 Expression * build_field_name_REALDECIMALconstant( const std::string & str ) { 217 assert( str[str.size()-1] == '.');219 if ( str[str.size()-1] != '.' ) throw SemanticError( "invalid tuple index " + str ); 218 220 Expression * ret = build_constantInteger( *new std::string( str.substr( 0, str.size()-1 ) ) ); 219 221 delete &str; -
src/Parser/lex.ll
r4203f71 r02153feb 10 10 * Created On : Sat Sep 22 08:58:10 2001 11 11 * Last Modified By : Peter A. Buhr 12 * Last Modified On : Mon Mar 13 08:36:17201713 * Update Count : 5 0612 * Last Modified On : Thu May 18 09:03:49 2017 13 * Update Count : 513 14 14 */ 15 15 … … 77 77 // numeric constants, CFA: '_' in constant 78 78 hex_quad {hex}("_"?{hex}){3} 79 integer_suffix "_"?(([uU] [lL]?)|([uU]("ll"|"LL")?)|([lL][uU]?)|("ll"|"LL")[uU]?)79 integer_suffix "_"?(([uU](("ll"|"LL"|[lL])[iI]|[iI]?("ll"|"LL"|[lL])?))|([iI](("ll"|"LL"|[lL])[uU]|[uU]?("ll"|"LL"|[lL])?))|(("ll"|"LL"|[lL])([iI][uU]|[uU]?[iI]?))) 80 80 81 81 octal_digits ({octal})|({octal}({octal}|"_")*{octal}) … … 91 91 92 92 decimal_digits ({decimal})|({decimal}({decimal}|"_")*{decimal}) 93 real_decimal {decimal_digits}"." 94 real_fraction "."{decimal_digits} 95 real_constant {decimal_digits} ?{real_fraction}93 real_decimal {decimal_digits}"."{exponent}?{floating_suffix}? 94 real_fraction "."{decimal_digits}{exponent}?{floating_suffix}? 95 real_constant {decimal_digits}{real_fraction} 96 96 exponent "_"?[eE]"_"?[+-]?{decimal_digits} 97 // GCC: D (double), DL (long double) and iI (imaginary) suffixes 98 floating_suffix "_"?([fFdDlL][iI]?|"DL"|[iI][lLfFdD]?) 99 //floating_suffix "_"?([fFdD]|[lL]|[D][L])|([iI][lLfFdD])|([lLfFdD][iI])) 97 // GCC: D (double) and iI (imaginary) suffixes, and DL (long double) 98 floating_suffix "_"?([fFdDlL][iI]?|[iI][lLfFdD]?|"DL") 100 99 floating_constant (({real_constant}{exponent}?)|({decimal_digits}{exponent})){floating_suffix}? 101 100
Note: See TracChangeset
for help on using the changeset viewer.