Changes in doc/user/user.tex [418d773a:23c27039]
- File:
-
- 1 edited
-
doc/user/user.tex (modified) (62 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/user/user.tex
r418d773a r23c27039 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Tue Feb 13 08:31:21201814 %% Update Count : 31 6113 %% Last Modified On : Wed Jan 31 22:29:25 2018 14 %% Update Count : 3147 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{ cquote}163 \begin{quote2} 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{ cquote}193 \end{quote2} 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 type-unsafe (©void *©) C ©bsearch© to binary search a sorted floating array:276 A simple example is leveraging the existing type-unsafe (©void *©) C ©bsearch© to binary search a sorted floating-point 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 values */ };284 double key = 5.0, vals[10] = { /* 10 sorted floating-point 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 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}§446 3.141®_®592®_®654; §\C{// floating point constant}§ 447 10®_®e®_®+1®_®00; §\C{// floating point constant}§ 448 0x®_®ff®_®ff®_®p®_®3; §\C{// hexadecimal floating point}§ 449 0x®_®1.ffff®_®ffff®_®p®_®128®_®l; §\C{// hexadecimal floating point 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 integral-constants 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.264715-1.1922i519 \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 user-defined types, only the integral-computation 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.524 503 525 504 … … 649 628 \end{cfa} 650 629 The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound: 651 \begin{ cquote}630 \begin{quote2} 652 631 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 653 632 \begin{cfa} … … 677 656 \end{cfa} 678 657 \end{tabular} 679 \end{ cquote}658 \end{quote2} 680 659 In this example, case 2 is always done if case 3 is done. 681 660 This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine. … … 751 730 ®int y = 1;® §\C{// unreachable initialization}§ 752 731 ®x = 7;® §\C{// unreachable code without label/branch}§ 753 case 0: ...732 case 3: ... 754 733 ... 755 734 ®int z = 0;® §\C{// unreachable initialization, cannot appear after case}§ 756 735 z = 2; 757 case 1:736 case 3: 758 737 ®x = z;® §\C{// without fall through, z is uninitialized}§ 759 738 } … … 840 819 Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C. 841 820 Therefore, the ©case© clause is extended with a list of values, as in: 842 \begin{ cquote}821 \begin{quote2} 843 822 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} 844 823 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ … … 870 849 \end{cfa} 871 850 \end{tabular} 872 \end{ cquote}851 \end{quote2} 873 852 In addition, two forms of subranges are allowed to specify case values: a new \CFA form and an existing GNU C form.\footnote{ 874 853 The GNU C form \emph{requires} spaces around the ellipse.} 875 \begin{ cquote}854 \begin{quote2} 876 855 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} 877 856 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{GNU C}} \\ … … 903 882 \end{cfa} 904 883 \end{tabular} 905 \end{ cquote}884 \end{quote2} 906 885 Lists of subranges are also allowed. 907 886 \begin{cfa} … … 923 902 } 924 903 \end{C++} 925 Since \CFA is non-object-oriented, the equivalent object-oriented program looks like:904 Since CFA is non-object-oriented, the equivalent object-oriented program looks like: 926 905 \begin{cfa} 927 906 struct S { int i, j; }; 928 int mem( S & ®this® ) { §\C{// explicit "this" parameter}§907 int mem( S &®this® ) { §\C{// explicit "this" parameter}§ 929 908 ®this.®i = 1; §\C{// "this" is not elided}§ 930 909 ®this.®j = 2; 931 910 } 932 911 \end{cfa} 933 but it is cumbersome having to write ``©this.©''many times in a member.912 but it is cumbersome having to write "©this.©" many times in a member. 934 913 935 914 \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. 936 915 \begin{cfa} 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}§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}§ 940 919 } 941 920 \end{cfa} … … 943 922 \begin{cfa} 944 923 struct T { double m, n; }; 945 int mem2( S & this1, T &this2 ) ®with this1, this2® {924 int mem2( S &this1, T &this2 ) ®with this1, this2® { 946 925 i = 1; j = 2; 947 926 m = 1.0; n = 2.0; … … 954 933 struct S1 { ... } s1; 955 934 struct S2 { ... } s2; 956 ®with s1® { §\C{// with statement}§935 ®with s1® { // with statement 957 936 // access fields of s1 without qualification 958 ®with s2® { §\C{// nesting}§937 ®with s2® { // nesting 959 938 // access fields of s1 and s2 without qualification 960 939 } … … 1066 1045 1067 1046 1068 \section{ AlternativeDeclarations}1069 \label{s: AlternativeDeclarations}1047 \section{Declarations} 1048 \label{s:Declarations} 1070 1049 1071 1050 C declaration syntax is notoriously confusing and error prone. 1072 1051 For example, many C programmers are confused by a declaration as simple as: 1073 \begin{ cquote}1052 \begin{quote2} 1074 1053 \begin{tabular}{@{}ll@{}} 1075 1054 \begin{cfa} … … 1079 1058 \raisebox{-0.75\totalheight}{\input{Cdecl}} 1080 1059 \end{tabular} 1081 \end{ cquote}1060 \end{quote2} 1082 1061 Is this an array of 5 pointers to integers or a \Index{pointer} to an array of 5 integers? 1083 If there is any doubt, it implies\Index{productivity} and \Index{safety} issues even for basic programs.1062 The fact this declaration is unclear to many C programmers means there are \Index{productivity} and \Index{safety} issues even for basic programs. 1084 1063 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. 1085 1064 For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way: 1086 1065 \begin{cfa} 1087 int ®(*®f®())[®5®]® {...}; §\C{ //definition}§1088 ... ®(*®f®())[®3®]® += 1; §\C{ //usage}§1066 int ®(*®f®())[®5®]® {...}; §\C{definition}§ 1067 ... ®(*®f®())[®3®]® += 1; §\C{usage}§ 1089 1068 \end{cfa} 1090 1069 Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}). … … 1095 1074 In the following example, \R{red} is the base type and \B{blue} is qualifiers. 1096 1075 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. 1097 \begin{ cquote}1076 \begin{quote2} 1098 1077 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1099 1078 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ … … 1110 1089 \end{cfa} 1111 1090 \end{tabular} 1112 \end{ cquote}1091 \end{quote2} 1113 1092 The only exception is \Index{bit field} specification, which always appear to the right of the base type. 1114 1093 % 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. 1115 1094 However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list. 1116 1095 For instance, variables ©x© and ©y© of type \Index{pointer} to integer are defined in \CFA as follows: 1117 \begin{ cquote}1096 \begin{quote2} 1118 1097 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1119 1098 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ … … 1126 1105 \end{cfa} 1127 1106 \end{tabular} 1128 \end{ cquote}1107 \end{quote2} 1129 1108 The downside of this semantics is the need to separate regular and \Index{pointer} declarations: 1130 \begin{ cquote}1109 \begin{quote2} 1131 1110 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1132 1111 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ … … 1141 1120 \end{cfa} 1142 1121 \end{tabular} 1143 \end{ cquote}1122 \end{quote2} 1144 1123 which is \Index{prescribing} a safety benefit. 1145 1124 Other examples are: 1146 \begin{ cquote}1125 \begin{quote2} 1147 1126 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} 1148 1127 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ … … 1180 1159 \end{cfa} 1181 1160 \end{tabular} 1182 \end{ cquote}1161 \end{quote2} 1183 1162 1184 1163 All type qualifiers, \eg ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, \eg: 1185 \begin{ cquote}1164 \begin{quote2} 1186 1165 \begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}} 1187 1166 \multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}} \\ … … 1201 1180 \end{cfa} 1202 1181 \end{tabular} 1203 \end{ cquote}1182 \end{quote2} 1204 1183 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} 1205 1184 The placement of a storage-class 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: 1206 \begin{ cquote}1185 \begin{quote2} 1207 1186 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} 1208 1187 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ … … 1222 1201 \end{cfa} 1223 1202 \end{tabular} 1224 \end{ cquote}1203 \end{quote2} 1225 1204 1226 1205 The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©: 1227 \begin{ cquote}1206 \begin{quote2} 1228 1207 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1229 1208 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 1230 1209 \begin{cfa} 1231 y = ( * int)x;1232 i = sizeof( [ 5 ] * int);1210 y = (®* int®)x; 1211 i = sizeof(®[ 5 ] * int®); 1233 1212 \end{cfa} 1234 1213 & 1235 1214 \begin{cfa} 1236 y = ( int *)x;1237 i = sizeof( int * [ 5 ]);1215 y = (®int *®)x; 1216 i = sizeof(®int * [ 5 ]®); 1238 1217 \end{cfa} 1239 1218 \end{tabular} 1240 \end{ cquote}1219 \end{quote2} 1241 1220 1242 1221 Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration. 1243 1222 Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style. 1244 Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX-like systems. 1223 Clearly, both styles need to be supported for some time due to existing C-style header-files, 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 floating-point 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 floating-point result because $x^{-y}=1/x^y$. 1235 Hence, it is important to designate exponent integral-constants as unsigned or signed: ©3 \ 3u© return an integral result, while ©3 \ 3© returns a floating-point result. 1236 Floating-point 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.264715-1.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 user-defined types, only the integral-computation versions are available. 1243 For returning an integral value, the user type ©T© must define multiplication, ©*©, and one, ©1©; 1244 for returning a floating-point value, an additional divide of type ©T© into a ©double© returning a ©double© (©double ?/?( double, T )©) is necessary for negative exponents. 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{ cquote}1262 \begin{quote2} 1263 1263 \begin{tabular}{@{}ll@{\hspace{2em}}l@{}} 1264 1264 \begin{cfa} … … 1278 1278 \end{cfa} 1279 1279 \end{tabular} 1280 \end{ cquote}1280 \end{quote2} 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{ cquote}1286 \begin{quote2} 1287 1287 \begin{tabular}{@{}l|l@{}} 1288 1288 \multicolumn{1}{c|}{explicit variable address} & \multicolumn{1}{c}{implicit variable address} \\ … … 1302 1302 \end{cfa} 1303 1303 \end{tabular} 1304 \end{ cquote}1304 \end{quote2} 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{ cquote}1311 \begin{quote2} 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{ cquote}1323 \end{quote2} 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 style-declarations; 1428 \CFA-style declarations (see \VRef{s: AlternativeDeclarations}) attempt to address this issue:1429 \begin{ cquote}1428 \CFA-style declarations (see \VRef{s:Declarations}) attempt to address this issue: 1429 \begin{quote2} 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{ cquote}1442 \end{quote2} 1443 1443 where the \CFA declaration is read left-to-right. 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 routine-prototypes in a single declaration, where the return type is distributed across \emph{all} routine names in the declaration list (see~\VRef{s: AlternativeDeclarations}), \eg:1899 Like C, it is possible to declare multiple routine-prototypes in a single declaration, where the return type is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), \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{ cquote}2074 \begin{quote2} 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{ cquote}2089 \end{quote2} 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 value.2274 For example, consider C's \Indexc{modf} function, which returns the integral and fractional part of a floating-point 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{ cquote}2997 \begin{quote2} 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{ cquote}3018 \end{quote2} 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 logical-or operator for I/O as it is the lowest-priority overloadable operator, other than assignment. 3029 3029 Therefore, fewer output expressions require parenthesis. 3030 \begin{ cquote}3030 \begin{quote2} 3031 3031 \begin{tabular}{@{}ll@{}} 3032 3032 \textbf{\CFA:} … … 3047 3047 \end{cfa} 3048 3048 \end{tabular} 3049 \end{ cquote}3049 \end{quote2} 3050 3050 There is a weak similarity between the \CFA logical-or operator and the Shell pipe-operator 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 type-inferencing occurs in a declaration where a variable's type is inferred from its initialization ex\-pression type. 3636 \begin{ cquote}3636 \begin{quote2} 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{ cquote}3660 \end{quote2} 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{ cquote}5723 \begin{quote2} 5724 5724 \input{../refrat/keywords} 5725 \end{ cquote}5725 \end{quote2} 5726 5726 5727 5727 … … 5730 5730 5731 5731 \Celeven prescribes the following standard header-files~\cite[\S~7.1.2]{C11} and \CFA adds to this list: 5732 \begin{ cquote}5732 \begin{quote2} 5733 5733 \begin{tabular}{@{}llllll|l@{}} 5734 5734 \multicolumn{6}{c|}{C11} & \multicolumn{1}{c}{\CFA} \\ … … 5790 5790 \end{tabular} 5791 5791 \end{tabular} 5792 \end{ cquote}5792 \end{quote2} 5793 5793 For the prescribed head-files, \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{ cquote}6533 \begin{quote2} 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{ cquote}6565 \end{quote2} 6566 6566 6567 6567 \begin{figure}
Note:
See TracChangeset
for help on using the changeset viewer.