Changeset 418d773a
 Timestamp:
 Feb 13, 2018, 11:37:00 AM (5 years ago)
 Branches:
 aaronthesis, armeh, cleanupdtors, deferred_resn, demangler, enum, forallpointerdecay, jacob/cs343translation, jenkinssandbox, master, newast, newastuniqueexpr, newenv, no_list, persistentindexer, pthreademulation, qualifiedEnum, resolvnew, with_gc
 Children:
 9c75137
 Parents:
 c4d4ecf
 Location:
 doc
 Files:

 2 edited
Legend:
 Unmodified
 Added
 Removed

doc/LaTeXmacros/common.tex
rc4d4ecf r418d773a 11 11 %% Created On : Sat Apr 9 10:06:17 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Sun Feb 4 10:38:26201814 %% Update Count : 36 513 %% Last Modified On : Tue Feb 13 08:19:07 2018 14 %% Update Count : 367 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 177 177 \makeatother 178 178 179 \newenvironment{ quote2}{%180 \list{}{\lstset{resetmargins=true,aboveskip=0pt,belowskip=0pt}\topsep=4pt\parsep=0pt\leftmargin=\parindent \rightmargin\leftmargin}%179 \newenvironment{cquote}{% 180 \list{}{\lstset{resetmargins=true,aboveskip=0pt,belowskip=0pt}\topsep=4pt\parsep=0pt\leftmargin=\parindentlnth\rightmargin\leftmargin}% 181 181 \item\relax 182 182 }{% 183 183 \endlist 184 }% quote2184 }% cquote 185 185 186 186 \newenvironment{rationale}{% 187 \begin{ quote2}\noindent$\Box$\enspace187 \begin{cquote}\noindent$\Box$\enspace 188 188 }{% 189 \hfill\enspace$\Box$\end{ quote2}189 \hfill\enspace$\Box$\end{cquote} 190 190 }% 191 191 … … 201 201 \newenvironment{syntax}{ 202 202 \paragraph{Syntax} 203 \begin{ quote2}203 \begin{cquote} 204 204 \begin{description}[noitemsep,leftmargin=\parindentlnth] 205 205 }{ 206 206 \end{description} 207 \end{ quote2}207 \end{cquote} 208 208 } 209 209 % \def\syntax{\paragraph{Syntax}\trivlist\parindent=.5in\item[\hskip.5in]} 
doc/user/user.tex
rc4d4ecf r418d773a 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Wed Jan 31 22:29:25201814 %% Update Count : 31 4713 %% Last Modified On : Tue Feb 13 08:31:21 2018 14 %% Update Count : 3161 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 161 161 Like \Index*[C++]{\CC{}}, there may be both an old and new ways to achieve the same effect. 162 162 For example, the following programs compare the \CFA, C, and \CC I/O mechanisms, where the programs output the same result. 163 \begin{ quote2}163 \begin{cquote} 164 164 \begin{tabular}{@{}l@{\hspace{1.5em}}l@{\hspace{1.5em}}l@{}} 165 165 \multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{C}} & \multicolumn{1}{c}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{\CC}} \\ … … 191 191 \end{cfa} 192 192 \end{tabular} 193 \end{ quote2}193 \end{cquote} 194 194 While the \CFA I/O looks similar to the \Index*[C++]{\CC{}} output style, there are important differences, such as automatic spacing between variables as in \Index*{Python} (see~\VRef{s:IOLibrary}). 195 195 … … 274 274 275 275 \begin{comment} 276 A simple example is leveraging the existing typeunsafe (©void *©) C ©bsearch© to binary search a sorted floating pointarray:276 A simple example is leveraging the existing typeunsafe (©void *©) C ©bsearch© to binary search a sorted floating array: 277 277 \begin{lstlisting} 278 278 void * bsearch( const void * key, const void * base, size_t dim, size_t size, … … 282 282 *(double *)t2 < *(double *)t1 ? 1 : 0; } 283 283 284 double key = 5.0, vals[10] = { /* 10 sorted floating pointvalues */ };284 double key = 5.0, vals[10] = { /* 10 sorted floating values */ }; 285 285 double * val = (double *)bsearch( &key, vals, 10, sizeof(vals[0]), comp ); $\C{// search sorted array}$ 286 286 \end{lstlisting} … … 444 444 0x®_®ff®_®ff; §\C{// hexadecimal constant}§ 445 445 0x®_®ef3d®_®aa5c; §\C{// hexadecimal constant}§ 446 3.141®_®592®_®654; §\C{// floating pointconstant}§447 10®_®e®_®+1®_®00; §\C{// floating pointconstant}§448 0x®_®ff®_®ff®_®p®_®3; §\C{// hexadecimal floating point}§449 0x®_®1.ffff®_®ffff®_®p®_®128®_®l; §\C{// hexadecimal floating pointlong constant}§446 3.141®_®592®_®654; §\C{// floating constant}§ 447 10®_®e®_®+1®_®00; §\C{// floating constant}§ 448 0x®_®ff®_®ff®_®p®_®3; §\C{// hexadecimal floating}§ 449 0x®_®1.ffff®_®ffff®_®p®_®128®_®l; §\C{// hexadecimal floating long constant}§ 450 450 L®_®§"\texttt{\textbackslash{x}}§®_®§\texttt{ff}§®_®§\texttt{ee}"§; §\C{// wide character constant}§ 451 451 \end{cfa} … … 501 501 \label{f:HeaderFileInterposition} 502 502 \end{figure} 503 504 505 \section{Exponentiation Operator} 506 507 C, \CC, and Java (and many other programming languages) have no exponentiation operator\index{exponentiation!operator}\index{operator!exponentiation}, \ie $x^y$, and instead use a routine, like \Indexc{pow}, to perform the exponentiation operation. 508 \CFA extends the basic operators with the exponentiation operator ©?\?©\index{?\\?@\lstinline$?\?$} and ©?\=?©\index{?\\=?@\lstinline$?\=?$}, as in, ©x \ y© and ©x \= y©, which means $x^y$ and $x \leftarrow x^y$. 509 The priority of the exponentiation operator is between the cast and multiplicative operators, so that ©w * (int)x \ (int)y * z© is parenthesized as ©((w * (((int)x) \ ((int)y))) * z)©. 510 511 As for \Index{division}, there are exponentiation operators for integral and floating types, including the builtin \Index{complex} types. 512 Unsigned integral exponentiation\index{exponentiation!unsigned integral} is performed with repeated multiplication\footnote{The multiplication computation is $O(\log y)$.} (or shifting if the base is 2). 513 Signed integral exponentiation\index{exponentiation!signed integral} is performed with repeated multiplication (or shifting if the base is 2), but yields a floating result because $x^{y}=1/x^y$. 514 Hence, it is important to designate exponent integralconstants as unsigned or signed: ©3 \ 3u© return an integral result, while ©3 \ 3© returns a floating result. 515 Floating exponentiation\index{exponentiation!floating} is performed using \Index{logarithm}s\index{exponentiation!logarithm}, so the base cannot be negative. 516 \begin{cfa} 517 sout  2 ®\® 8u  4 ®\® 3u  4 ®\® 3u  4 ®\® 3  4 ®\® 3  4.0 ®\® 2.1  (1.0f+2.0fi) ®\® (3.0f+2.0fi)  endl; 518 256 64 64 0.015625 0.015625 18.3791736799526 0.2647151.1922i 519 \end{cfa} 520 Parenthesis are necessary for the complex constants or the expresion is parsed as ©1.0f+(2.0fi \ 3.0f)+2.0fi©. 521 The exponentiation operator is available for all the basic types, but for userdefined types, only the integralcomputation versions are available. 522 For returning an integral value, the user type ©T© must define multiplication, ©*©, and one, ©1©; 523 for returning a floating value, an additional divide of type ©T© into a ©double© returning a ©double© (©double ?/?( double, T )©) is necessary for negative exponents. 503 524 504 525 … … 628 649 \end{cfa} 629 650 The ability to fallthrough to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound: 630 \begin{ quote2}651 \begin{cquote} 631 652 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 632 653 \begin{cfa} … … 656 677 \end{cfa} 657 678 \end{tabular} 658 \end{ quote2}679 \end{cquote} 659 680 In this example, case 2 is always done if case 3 is done. 660 681 This control flow is difficult to simulate with if statements or a ©switch© statement without fallthrough as code must be duplicated or placed in a separate routine. … … 730 751 ®int y = 1;® §\C{// unreachable initialization}§ 731 752 ®x = 7;® §\C{// unreachable code without label/branch}§ 732 case 3: ...753 case 0: ... 733 754 ... 734 755 ®int z = 0;® §\C{// unreachable initialization, cannot appear after case}§ 735 756 z = 2; 736 case 3:757 case 1: 737 758 ®x = z;® §\C{// without fall through, z is uninitialized}§ 738 759 } … … 819 840 Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C. 820 841 Therefore, the ©case© clause is extended with a list of values, as in: 821 \begin{ quote2}842 \begin{cquote} 822 843 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} 823 844 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ … … 849 870 \end{cfa} 850 871 \end{tabular} 851 \end{ quote2}872 \end{cquote} 852 873 In addition, two forms of subranges are allowed to specify case values: a new \CFA form and an existing GNU C form.\footnote{ 853 874 The GNU C form \emph{requires} spaces around the ellipse.} 854 \begin{ quote2}875 \begin{cquote} 855 876 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} 856 877 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{GNU C}} \\ … … 882 903 \end{cfa} 883 904 \end{tabular} 884 \end{ quote2}905 \end{cquote} 885 906 Lists of subranges are also allowed. 886 907 \begin{cfa} … … 902 923 } 903 924 \end{C++} 904 Since CFA is nonobjectoriented, the equivalent objectoriented program looks like:925 Since \CFA is nonobjectoriented, the equivalent objectoriented program looks like: 905 926 \begin{cfa} 906 927 struct S { int i, j; }; 907 int mem( S & ®this® ) { §\C{// explicit "this" parameter}§928 int mem( S & ®this® ) { §\C{// explicit "this" parameter}§ 908 929 ®this.®i = 1; §\C{// "this" is not elided}§ 909 930 ®this.®j = 2; 910 931 } 911 932 \end{cfa} 912 but it is cumbersome having to write "©this.©"many times in a member.933 but it is cumbersome having to write ``©this.©'' many times in a member. 913 934 914 935 \CFA provides a ©with© clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elided the "©this.©" by opening a scope containing field identifiers, changing the qualified fields into variables and giving an opportunity for optimizing qualified references. 915 936 \begin{cfa} 916 int mem( S & this ) ®with this® { §\C{// with clause}§917 i = 1; §\C{\color{red}// this >i}§918 j = 2; §\C{\color{red}// this >j}§937 int mem( S & this ) ®with this® { §\C{// with clause}§ 938 i = 1; §\C{\color{red}// this.i}§ 939 j = 2; §\C{\color{red}// this.j}§ 919 940 } 920 941 \end{cfa} … … 922 943 \begin{cfa} 923 944 struct T { double m, n; }; 924 int mem2( S & this1, T &this2 ) ®with this1, this2® {945 int mem2( S & this1, T & this2 ) ®with this1, this2® { 925 946 i = 1; j = 2; 926 947 m = 1.0; n = 2.0; … … 933 954 struct S1 { ... } s1; 934 955 struct S2 { ... } s2; 935 ®with s1® { // with statement956 ®with s1® { §\C{// with statement}§ 936 957 // access fields of s1 without qualification 937 ®with s2® { // nesting958 ®with s2® { §\C{// nesting}§ 938 959 // access fields of s1 and s2 without qualification 939 960 } … … 1045 1066 1046 1067 1047 \section{ Declarations}1048 \label{s: Declarations}1068 \section{Alternative Declarations} 1069 \label{s:AlternativeDeclarations} 1049 1070 1050 1071 C declaration syntax is notoriously confusing and error prone. 1051 1072 For example, many C programmers are confused by a declaration as simple as: 1052 \begin{ quote2}1073 \begin{cquote} 1053 1074 \begin{tabular}{@{}ll@{}} 1054 1075 \begin{cfa} … … 1058 1079 \raisebox{0.75\totalheight}{\input{Cdecl}} 1059 1080 \end{tabular} 1060 \end{ quote2}1081 \end{cquote} 1061 1082 Is this an array of 5 pointers to integers or a \Index{pointer} to an array of 5 integers? 1062 The fact this declaration is unclear to many C programmers means there are\Index{productivity} and \Index{safety} issues even for basic programs.1083 If there is any doubt, it implies \Index{productivity} and \Index{safety} issues even for basic programs. 1063 1084 Another example of confusion results from the fact that a routine name and its parameters are embedded within the return type, mimicking the way the return value is used at the routine's call site. 1064 1085 For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way: 1065 1086 \begin{cfa} 1066 int ®(*®f®())[®5®]® {...}; §\C{ definition}§1067 ... ®(*®f®())[®3®]® += 1; §\C{ usage}§1087 int ®(*®f®())[®5®]® {...}; §\C{// definition}§ 1088 ... ®(*®f®())[®3®]® += 1; §\C{// usage}§ 1068 1089 \end{cfa} 1069 1090 Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}). … … 1074 1095 In the following example, \R{red} is the base type and \B{blue} is qualifiers. 1075 1096 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. 1076 \begin{ quote2}1097 \begin{cquote} 1077 1098 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1078 1099 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ … … 1089 1110 \end{cfa} 1090 1111 \end{tabular} 1091 \end{ quote2}1112 \end{cquote} 1092 1113 The only exception is \Index{bit field} specification, which always appear to the right of the base type. 1093 1114 % Specifically, the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array or function return value, and parentheses ©()© are used to indicate a routine parameter. 1094 1115 However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list. 1095 1116 For instance, variables ©x© and ©y© of type \Index{pointer} to integer are defined in \CFA as follows: 1096 \begin{ quote2}1117 \begin{cquote} 1097 1118 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1098 1119 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ … … 1105 1126 \end{cfa} 1106 1127 \end{tabular} 1107 \end{ quote2}1128 \end{cquote} 1108 1129 The downside of this semantics is the need to separate regular and \Index{pointer} declarations: 1109 \begin{ quote2}1130 \begin{cquote} 1110 1131 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1111 1132 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ … … 1120 1141 \end{cfa} 1121 1142 \end{tabular} 1122 \end{ quote2}1143 \end{cquote} 1123 1144 which is \Index{prescribing} a safety benefit. 1124 1145 Other examples are: 1125 \begin{ quote2}1146 \begin{cquote} 1126 1147 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} 1127 1148 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ … … 1159 1180 \end{cfa} 1160 1181 \end{tabular} 1161 \end{ quote2}1182 \end{cquote} 1162 1183 1163 1184 All type qualifiers, \eg ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, \eg: 1164 \begin{ quote2}1185 \begin{cquote} 1165 1186 \begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}} 1166 1187 \multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}} \\ … … 1180 1201 \end{cfa} 1181 1202 \end{tabular} 1182 \end{ quote2}1203 \end{cquote} 1183 1204 All declaration qualifiers, \eg ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier} 1184 1205 The placement of a storageclass specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} \eg: 1185 \begin{ quote2}1206 \begin{cquote} 1186 1207 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} 1187 1208 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ … … 1201 1222 \end{cfa} 1202 1223 \end{tabular} 1203 \end{ quote2}1224 \end{cquote} 1204 1225 1205 1226 The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudoroutine ©sizeof©: 1206 \begin{ quote2}1227 \begin{cquote} 1207 1228 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1208 1229 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 1209 1230 \begin{cfa} 1210 y = ( ®* int®)x;1211 i = sizeof( ®[ 5 ] * int®);1231 y = (* int)x; 1232 i = sizeof([ 5 ] * int); 1212 1233 \end{cfa} 1213 1234 & 1214 1235 \begin{cfa} 1215 y = ( ®int *®)x;1216 i = sizeof( ®int * [ 5 ]®);1236 y = (int *)x; 1237 i = sizeof(int * [ 5 ]); 1217 1238 \end{cfa} 1218 1239 \end{tabular} 1219 \end{ quote2}1240 \end{cquote} 1220 1241 1221 1242 Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration. 1222 1243 Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style. 1223 Clearly, both styles need to be supported for some time due to existing Cstyle headerfiles, particularly for UNIX systems. 1224 1225 1226 \section{Exponentiation Operator} 1227 1228 C, \CC, and Java (and many other programming languages) have no exponentiation operator\index{exponentiation!operator}\index{operator!exponentiation}, \ie $x^y$, and instead use a routine, like \Indexc{pow}, to perform the exponentiation operation. 1229 \CFA extends the basic operators with the exponentiation operator ©?\?©\index{?\\?@\lstinline$?\?$} and ©?\=?©\index{?\\=?@\lstinline$?\=?$}, as in, ©x \ y© and ©x \= y©, which means $x^y$ and $x \leftarrow x^y$. 1230 The priority of the exponentiation operator is between the cast and multiplicative operators, so that ©w * (int)x \ (int)y * z© is parenthesized as ©((w * (((int)x) \ ((int)y))) * z)©. 1231 1232 As for \Index{division}, there are exponentiation operators for integral and floatingpoint types, including the builtin \Index{complex} types. 1233 Unsigned integral exponentiation\index{exponentiation!unsigned integral} is performed with repeated multiplication\footnote{The multiplication computation is optimized to $O(\log y)$.} (or shifting if the base is 2). 1234 Signed integral exponentiation\index{exponentiation!signed integral} is performed with repeated multiplication (or shifting if the base is 2), but yields a floatingpoint result because $x^{y}=1/x^y$. 1235 Hence, it is important to designate exponent integralconstants as unsigned or signed: ©3 \ 3u© return an integral result, while ©3 \ 3© returns a floatingpoint result. 1236 Floatingpoint exponentiation\index{exponentiation!floating point} is performed using \Index{logarithm}s\index{exponentiation!logarithm}, so the base cannot be negative. 1237 \begin{cfa} 1238 sout  2 ®\® 8u  4 ®\® 3u  4 ®\® 3u  4 ®\® 3  4 ®\® 3  4.0 ®\® 2.1  (1.0f+2.0fi) ®\® (3.0f+2.0fi)  endl; 1239 256 64 64 0.015625 0.015625 18.3791736799526 0.2647151.1922i 1240 \end{cfa} 1241 Parenthesis are necessary for the complex constants or the expresion is parsed as ©1.0f+(2.0fi \ 3.0f)+2.0fi©. 1242 The exponentiation operator is available for all the basic types, but for userdefined types, only the integralcomputation versions are available. 1243 For returning an integral value, the user type ©T© must define multiplication, ©*©, and one, ©1©; 1244 for returning a floatingpoint value, an additional divide of type ©T© into a ©double© returning a ©double© (©double ?/?( double, T )©) is necessary for negative exponents. 1244 Clearly, both styles need to be supported for some time due to existing Cstyle headerfiles, particularly for UNIXlike systems. 1245 1245 1246 1246 … … 1260 1260 A program \newterm{object} is a region of data storage in the execution environment, the contents of which can represent values. 1261 1261 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: 1262 \begin{ quote2}1262 \begin{cquote} 1263 1263 \begin{tabular}{@{}ll@{\hspace{2em}}l@{}} 1264 1264 \begin{cfa} … … 1278 1278 \end{cfa} 1279 1279 \end{tabular} 1280 \end{ quote2}1280 \end{cquote} 1281 1281 where the right example is how the compiler logically interprets the variables in the left example. 1282 1282 Since a variable name only points to one address during its lifetime, it is an \Index{immutable} \Index{pointer}; … … 1284 1284 In general, variable addresses are stored in instructions instead of loaded from memory, and hence may not occupy storage. 1285 1285 These approaches are contrasted in the following: 1286 \begin{ quote2}1286 \begin{cquote} 1287 1287 \begin{tabular}{@{}ll@{}} 1288 1288 \multicolumn{1}{c}{explicit variable address} & \multicolumn{1}{c}{implicit variable address} \\ … … 1302 1302 \end{cfa} 1303 1303 \end{tabular} 1304 \end{ quote2}1304 \end{cquote} 1305 1305 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. 1306 1306 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 \Index{instruction decoding}. … … 1309 1309 (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 if the literal is embedded directly into instructions.) 1310 1310 Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg: 1311 \begin{ quote2}1311 \begin{cquote} 1312 1312 \begin{tabular}{@{}l@{\hspace{2em}}l@{}} 1313 1313 \begin{cfa} … … 1321 1321 \raisebox{0.5\totalheight}{\input{pointer2.pstex_t}} 1322 1322 \end{tabular} 1323 \end{ quote2}1323 \end{cquote} 1324 1324 1325 1325 Notice, an address has a \Index{duality}\index{address!duality}: a location in memory or the value at that location. … … 1426 1426 The position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers. 1427 1427 The ©const© qualifier cannot be moved before the pointer/reference qualifier for C styledeclarations; 1428 \CFAstyle declarations (see \VRef{s: Declarations}) attempt to address this issue:1429 \begin{ quote2}1428 \CFAstyle declarations (see \VRef{s:AlternativeDeclarations}) attempt to address this issue: 1429 \begin{cquote} 1430 1430 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1431 1431 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ … … 1440 1440 \end{cfa} 1441 1441 \end{tabular} 1442 \end{ quote2}1442 \end{cquote} 1443 1443 where the \CFA declaration is read lefttoright. 1444 1444 … … 1518 1518 \begin{cfa} 1519 1519 void f( int i ); 1520 void (* fp)( int ); §\C{// routine pointer}§1520 void (* fp)( int ); §\C{// routine pointer}§ 1521 1521 fp = f; §\C{// reference initialization}§ 1522 1522 fp = &f; §\C{// pointer initialization}§ … … 1897 1897 \end{cfa} 1898 1898 This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa). 1899 Like C, it is possible to declare multiple routineprototypes in a single declaration, where the return type is distributed across \emph{all} routine names in the declaration list (see~\VRef{s: Declarations}), \eg:1899 Like C, it is possible to declare multiple routineprototypes in a single declaration, where the return type is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:AlternativeDeclarations}), \eg: 1900 1900 \begin{cfa} 1901 1901 C : const double bar1(), bar2( int ), bar3( double ); … … 2072 2072 Default arguments and overloading (see Section 24) are complementary. 2073 2073 While in theory default arguments can be simulated with overloading, as in: 2074 \begin{ quote2}2074 \begin{cquote} 2075 2075 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 2076 2076 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{default arguments}} & \multicolumn{1}{c}{\textbf{overloading}} \\ … … 2087 2087 \end{cfa} 2088 2088 \end{tabular} 2089 \end{ quote2}2089 \end{cquote} 2090 2090 the number of required overloaded routines is linear in the number of default values, which is unacceptable growth. 2091 2091 In general, overloading should only be used over default arguments if the body of the routine is significantly different. … … 2224 2224 The following program in undefined in \CFA (and Indexc{gcc}) 2225 2225 \begin{cfa} 2226 [* [int]( int )] foo() { §\C{// int (* foo())( int )}§2226 [* [int]( int )] foo() { §\C{// int (* foo())( int )}§ 2227 2227 int ®i® = 7; 2228 2228 int bar( int p ) { … … 2233 2233 } 2234 2234 int main() { 2235 * [int]( int ) fp = foo(); §\C{// int (* fp)( int )}§2235 * [int]( int ) fp = foo(); §\C{// int (* fp)( int )}§ 2236 2236 sout  fp( 3 )  endl; 2237 2237 } … … 2272 2272 In the latter approach, additional return values are passed as pointer parameters. 2273 2273 A pointer parameter is assigned inside the routine to emulate a return. 2274 For example, consider C's \Indexc{modf} function, which returns the integral and fractional part of a floating pointvalue.2274 For example, consider C's \Indexc{modf} function, which returns the integral and fractional part of a floating value. 2275 2275 \begin{cfa} 2276 2276 double modf( double x, double * i ); §\C{// from include math.h}§ … … 2995 2995 2996 2996 The common case is printing out a sequence of variables separated by whitespace. 2997 \begin{ quote2}2997 \begin{cquote} 2998 2998 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 2999 2999 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{\CC}} \\ … … 3016 3016 \end{cfa} 3017 3017 \end{tabular} 3018 \end{ quote2}3018 \end{cquote} 3019 3019 The \CFA form has half the characters of the \CC form, and is similar to \Index*{Python} I/O with respect to implicit separators. 3020 3020 Similar simplification occurs for \Index{tuple} I/O, which prints all tuple values separated by ``\lstinline[showspaces=true]@, @''. … … 3028 3028 Finally, \CFA uses the logicalor operator for I/O as it is the lowestpriority overloadable operator, other than assignment. 3029 3029 Therefore, fewer output expressions require parenthesis. 3030 \begin{ quote2}3030 \begin{cquote} 3031 3031 \begin{tabular}{@{}ll@{}} 3032 3032 \textbf{\CFA:} … … 3047 3047 \end{cfa} 3048 3048 \end{tabular} 3049 \end{ quote2}3049 \end{cquote} 3050 3050 There is a weak similarity between the \CFA logicalor operator and the Shell pipeoperator for moving data, where data flows in the correct direction for input but the opposite direction for output. 3051 3051 … … 3420 3420 int id; 3421 3421 float size; 3422 Parts * optionalParts;3422 Parts * optionalParts; 3423 3423 }; 3424 3424 … … 3634 3634 3635 3635 Auto typeinferencing occurs in a declaration where a variable's type is inferred from its initialization ex\pression type. 3636 \begin{ quote2}3636 \begin{cquote} 3637 3637 \begin{tabular}{@{}l@{\hspace{3em}}ll@{}} 3638 3638 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CC}} & \multicolumn{1}{c}{\textbf{\Indexc{gcc}}} \\ … … 3658 3658 \end{cfa} 3659 3659 \end{tabular} 3660 \end{ quote2}3660 \end{cquote} 3661 3661 The two important capabilities are: 3662 3662 \begin{itemize} … … 3806 3806 3807 3807 generic(type T) 3808 typedef int (* predicate)(T);3808 typedef int (* predicate)(T); 3809 3809 generic(type Captured, type T) 3810 typedef void (* callback)(Captured, T);3810 typedef void (* callback)(Captured, T); 3811 3811 3812 3812 generic(type T) 3813 void find(int length, T * array,3813 void find(int length, T * array, 3814 3814 predicate(T) p, callback(void *, T)f) { 3815 3815 int i; … … 3835 3835 struct LinkedListElem { 3836 3836 T elem; 3837 LinkedListElem(T) * next;3837 LinkedListElem(T) * next; 3838 3838 }; 3839 3839 3840 LinkedListElem *++?(LinkedListElem ** elem) {3841 return * elem = elem>next;3840 LinkedListElem *++?(LinkedListElem ** elem) { 3841 return * elem = elem>next; 3842 3842 } 3843 3843 3844 3844 generic (type T) 3845 3845 struct LinkedList { 3846 LinkedListElem(T) * head;3846 LinkedListElem(T) * head; 3847 3847 unsigned int size; 3848 3848 } 3849 3849 3850 3850 generic (type T  bool ?==?(T, T)) 3851 bool contains(LinkedList(T) * list, T elem) {3852 for(LinkedListElem * iter = list>head; iter != 0; ++iter) {3851 bool contains(LinkedList(T) * list, T elem) { 3852 for(LinkedListElem * iter = list>head; iter != 0; ++iter) { 3853 3853 if (iter>elem == elem) return true; 3854 3854 } … … 4063 4063 // transferring requires mutual exclusion and calls deleteJob 4064 4064 4065 void transferJob(mutex Worker & from, Worker &to) {4065 void transferJob(mutex Worker & from, Worker & to) { 4066 4066 ... 4067 4067 deleteJob(j); … … 5001 5001 #include <unistd.h> 5002 5002 } 5003 size_t fileSize( const char * path ) {5003 size_t fileSize( const char * path ) { 5004 5004 struct stat s; 5005 5005 stat(path, &s); … … 5038 5038 #[link(name = "libc")] 5039 5039 extern { 5040 fn stat(path: * const u8,5041 buf: * mut stat_t) > c_int;5042 } 5043 fn fileSize(path: * const u8) > size_t5040 fn stat(path: * const u8, 5041 buf: * mut stat_t) > c_int; 5042 } 5043 fn fileSize(path: * const u8) > size_t 5044 5044 { 5045 5045 unsafe { … … 5063 5063 generic(type T, type N  5064 5064 { int ?<?(N, N); }) 5065 T * maximize(N (*f)(const T&),5065 T * maximize(N (*f)(const T&), 5066 5066 int n, T *a) { 5067 T * bestX = NULL;5067 T * bestX = NULL; 5068 5068 N bestN; 5069 5069 for (int i = 0; i < n; i++) { … … 5077 5077 } 5078 5078 5079 string * longest(int n, string *p)5079 string * longest(int n, string *p) 5080 5080 { 5081 5081 return maximize(length, n, p); … … 5085 5085 \begin{cfa} 5086 5086 template<typename T, typename F> 5087 T * maximize(const F &f,5087 T * maximize(const F &f, 5088 5088 int n, T *a) { 5089 5089 typedef decltype(f(a[0])) N; 5090 T * bestX = NULL;5090 T * bestX = NULL; 5091 5091 N bestN; 5092 5092 for (int i = 0; i < n; i++) { … … 5100 5100 } 5101 5101 5102 string * longest(int n, string *p) {5102 string * longest(int n, string *p) { 5103 5103 return maximize( 5104 5104 [](const string &s) { … … 5258 5258 \begin{cfa} 5259 5259 task Nonzero { 5260 int * data;5260 int * data; 5261 5261 int start; 5262 5262 int end; … … 5721 5721 \CFA introduces the following new keywords. 5722 5722 5723 \begin{ quote2}5723 \begin{cquote} 5724 5724 \input{../refrat/keywords} 5725 \end{ quote2}5725 \end{cquote} 5726 5726 5727 5727 … … 5730 5730 5731 5731 \Celeven prescribes the following standard headerfiles~\cite[\S~7.1.2]{C11} and \CFA adds to this list: 5732 \begin{ quote2}5732 \begin{cquote} 5733 5733 \begin{tabular}{@{}lllllll@{}} 5734 5734 \multicolumn{6}{c}{C11} & \multicolumn{1}{c}{\CFA} \\ … … 5790 5790 \end{tabular} 5791 5791 \end{tabular} 5792 \end{ quote2}5792 \end{cquote} 5793 5793 For the prescribed headfiles, \CFA uses header interposition to wraps these includes in an ©extern "C"©; 5794 5794 hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}). … … 6531 6531 The following factorial programs contrast using GMP with the \CFA and C interfaces, where the output from these programs appears in \VRef[Figure]{f:MultiPrecisionFactorials}. 6532 6532 (Compile with flag \Indexc{lgmp} to link with the GMP library.) 6533 \begin{ quote2}6533 \begin{cquote} 6534 6534 \begin{tabular}{@{}l@{\hspace{\parindentlnth}}@{\hspace{\parindentlnth}}l@{}} 6535 6535 \multicolumn{1}{c@{\hspace{\parindentlnth}}}{\textbf{\CFA}} & \multicolumn{1}{@{\hspace{\parindentlnth}}c}{\textbf{C}} \\ … … 6563 6563 \end{cfa} 6564 6564 \end{tabular} 6565 \end{ quote2}6565 \end{cquote} 6566 6566 6567 6567 \begin{figure}
Note: See TracChangeset
for help on using the changeset viewer.