Changes in / [46b4259:473d8c82]
- Location:
- doc
- Files:
-
- 2 edited
-
LaTeXmacros/common.tex (modified) (2 diffs)
-
user/user.tex (modified) (32 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/LaTeXmacros/common.tex
r46b4259 r473d8c82 11 11 %% Created On : Sat Apr 9 10:06:17 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : T hu Aug 4 13:22:46201614 %% Update Count : 2 3013 %% Last Modified On : Tue Aug 2 17:02:02 2016 14 %% Update Count : 228 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 255 255 literate={-}{\raisebox{-0.15ex}{\texttt{-}}}1 {^}{\raisebox{0.6ex}{$\scriptscriptstyle\land\,$}}1 256 256 {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 {_}{\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}1 {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1 257 {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 ,257 {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {...}{$\dots$}2, 258 258 }% 259 259 -
doc/user/user.tex
r46b4259 r473d8c82 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Sun Aug 14 08:23:06201614 %% Update Count : 1 32313 %% Last Modified On : Tue Aug 2 17:39:02 2016 14 %% Update Count : 1286 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 317 317 318 318 \item 319 \Indexc{-no-include-std hdr}\index{compilation option!-no-include-stdhdr@©-no-include-stdhdr©}319 \Indexc{-no-include-std}\index{compilation option!-no-include-std@©-no-include-std©} 320 320 Do not supply ©extern "C"© wrappers for \Celeven standard include files (see~\VRef{s:StandardHeaders}). 321 321 \textbf{This option is \emph{not} the default.} … … 807 807 808 808 809 \section{Backquote Identifiers}810 \label{s:BackquoteIdentifiers}811 812 \CFA accommodates keyword clashes by syntactic transformations using the \CFA backquote escape-mechanism:813 \begin{lstlisting}814 int `otype` = 3; // make keyword an identifier815 double `choose` = 3.5;816 \end{lstlisting}817 Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to an non-keyword name.818 Clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled automatically using the preprocessor, ©#include_next© and ©-I filename©:819 \begin{lstlisting}820 // include file uses the CFA keyword "otype".821 #if ! defined( otype ) // nesting ?822 #define otype `otype`823 #define __CFA_BFD_H__824 #endif // ! otype825 826 #include_next <bfd.h> // must have internal check for multiple expansion827 828 #if defined( otype ) && defined( __CFA_BFD_H__ ) // reset only if set829 #undef otype830 #undef __CFA_BFD_H__831 #endif // otype && __CFA_BFD_H__832 \end{lstlisting}833 834 835 809 \section{Type Operators} 836 810 … … 1037 1011 Alternatively, prototype definitions can be eliminated by using a two-pass compilation, and implicitly creating header files for exports. 1038 1012 The former is easy to do, while the latter is more complex. 1039 1040 Furthermore, named arguments do not work well in a \CFA-style programming-languages because they potentially introduces a new criteria for type matching. 1041 For example, it is technically possible to disambiguate between these two overloaded definitions of ©f© based on named arguments at the call site: 1042 \begin{lstlisting} 1043 int f( int i, int j ); 1044 int f( int x, double y ); 1045 1046 f( j : 3, i : 4 ); §\C{// 1st f}§ 1047 f( x : 7, y : 8.1 ); §\C{// 2nd f}§ 1048 f( 4, 5 ); §\C{// ambiguous call}§ 1049 \end{lstlisting} 1050 However, named arguments compound routine resolution in conjunction with conversions: 1051 \begin{lstlisting} 1052 f( i : 3, 5.7 ); §\C{// ambiguous call ?}§ 1053 \end{lstlisting} 1054 Depending on the cost associated with named arguments, this call could be resolvable or ambiguous. 1055 Adding named argument into the routine resolution algorithm does not seem worth the complexity. 1056 Therefore, \CFA does \emph{not} attempt to support named arguments. 1013 Currently, \CFA does \emph{not} attempt to support named arguments. 1057 1014 1058 1015 \item[Default Arguments] … … 1064 1021 the allowable positional calls are: 1065 1022 \begin{lstlisting} 1066 p(); 1067 p( 4 ); 1068 p( 4, 4 ); 1069 p( 4, 4, 4 ); 1023 p(); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ 1024 p( 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§ 1025 p( 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§ 1026 p( 4, 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§ 1070 1027 // empty arguments 1071 p( , 4, 4 ); 1072 p( 4, , 4 ); 1073 p( 4, 4, ); 1074 p( 4, , ); 1075 p( , 4, ); 1076 p( , , 4 ); 1077 p( , , ); 1028 p( , 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§ 1029 p( 4, , 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§ 1030 p( 4, 4, ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§ 1031 p( 4, , ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§ 1032 p( , 4, ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§ 1033 p( , , 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§ 1034 p( , , ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ 1078 1035 \end{lstlisting} 1079 1036 Here the missing arguments are inserted from the default values in the parameter list. … … 1110 1067 The conflict occurs because both named and ellipse arguments must appear after positional arguments, giving two possibilities: 1111 1068 \begin{lstlisting} 1112 p( /* positional */, . .., /* named */ );1113 p( /* positional */, /* named */, . .. );1069 p( /* positional */, . . ., /* named */ ); 1070 p( /* positional */, /* named */, . . . ); 1114 1071 \end{lstlisting} 1115 1072 While it is possible to implement both approaches, the first possibly is more complex than the second, \eg: 1116 1073 \begin{lstlisting} 1117 p( int x, int y, int z, . .. );1118 p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, . .., /* named */ );}§1119 p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, . .. );}§1074 p( int x, int y, int z, . . . ); 1075 p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, . . ., /* named */ );}§ 1076 p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, . . . );}§ 1120 1077 \end{lstlisting} 1121 1078 In the first call, it is necessary for the programmer to conceptually rewrite the call, changing named arguments into positional, before knowing where the ellipse arguments begin. … … 1125 1082 The problem is exacerbated with default arguments, \eg: 1126 1083 \begin{lstlisting} 1127 void p( int x, int y = 2, int z = 3. .. );1128 p( 1, 4, 5, 6, z : 3 ); §\C{// assume p( /* positional */, . .., /* named */ );}§1129 p( 1, z : 3, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, . .. );}§1084 void p( int x, int y = 2, int z = 3. . . ); 1085 p( 1, 4, 5, 6, z : 3 ); §\C{// assume p( /* positional */, . . ., /* named */ );}§ 1086 p( 1, z : 3, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, . . . );}§ 1130 1087 \end{lstlisting} 1131 1088 The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments; … … 1172 1129 \subsection{Type Nesting} 1173 1130 1174 \CFA allows \Index{type nesting}, and type qualification of the nested typ res (see \VRef[Figure]{f:TypeNestingQualification}), where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification.1131 \CFA allows \Index{type nesting}, and type qualification of the nested types (see \VRef[Figure]{f:TypeNestingQualification}), where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification. 1175 1132 \begin{figure} 1176 \centering1177 1133 \begin{tabular}{@{}l@{\hspace{3em}}l|l@{}} 1178 1134 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}} & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}} & \multicolumn{1}{|c}{\textbf{\CFA}} \\ … … 1441 1397 Mass assignment has the following form: 1442 1398 \begin{lstlisting} 1443 [ §\emph{lvalue}§, ... 1399 [ §\emph{lvalue}§, ..., §\emph{lvalue}§ ] = §\emph{expr}§; 1444 1400 \end{lstlisting} 1445 1401 \index{lvalue} … … 1481 1437 Multiple assignment has the following form: 1482 1438 \begin{lstlisting} 1483 [ §\emph{lvalue}§, . .. , §\emph{lvalue}§ ] = [ §\emph{expr}§, ..., §\emph{expr}§ ];1439 [ §\emph{lvalue}§, . . ., §\emph{lvalue}§ ] = [ §\emph{expr}§, . . ., §\emph{expr}§ ]; 1484 1440 \end{lstlisting} 1485 1441 \index{lvalue} … … 1917 1873 \begin{lstlisting} 1918 1874 switch ( i ) { 1919 case ®1, 3, 5®:1875 ®case 1, 3, 5®: 1920 1876 ... 1921 case ®2, 4, 6®:1877 ®case 2, 4, 6®: 1922 1878 ... 1923 1879 } … … 1950 1906 \begin{lstlisting} 1951 1907 switch ( i ) { 1952 case ®1~5:®1908 ®case 1~5:® 1953 1909 ... 1954 case ®10~15:®1910 ®case 10~15:® 1955 1911 ... 1956 1912 } … … 1959 1915 \begin{lstlisting} 1960 1916 switch ( i ) 1961 case ®1 ... 5®:1917 case 1 ... 5: 1962 1918 ... 1963 case ®10 ... 15®:1919 case 10 ... 15: 1964 1920 ... 1965 1921 } … … 4413 4369 4414 4370 4415 \section{Incompatible}4416 4417 The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{ANSI14:C++}.4418 4419 \begin{enumerate}4420 \item4421 \begin{description}4422 \item[Change:] add new keywords \\4423 New keywords are added to \CFA (see~\VRef{s:NewKeywords}).4424 \item[Rationale:] keywords added to implement new semantics of \CFA.4425 \item[Effect on original feature:] change to semantics of well-defined feature. \\4426 Any ISO C programs using these keywords as identifiers are invalid \CFA programs.4427 \item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}):4428 \item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.4429 \end{description}4430 4431 \item4432 \begin{description}4433 \item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:4434 \begin{lstlisting}4435 int rtn( int i );4436 int rtn( char c );4437 rtn( 'x' ); §\C{// programmer expects 2nd rtn to be called}§4438 \end{lstlisting}4439 \item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.4440 In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.4441 \begin{lstlisting}4442 sout | 'x' | " " | (int)'x' | endl;4443 x 1204444 \end{lstlisting}4445 Having to cast ©'x'© to ©char© is non-intuitive.4446 \item[Effect on original feature:] change to semantics of well-defined feature that depend on:4447 \begin{lstlisting}4448 sizeof( 'x' ) == sizeof( int )4449 \end{lstlisting}4450 no long work the same in \CFA programs.4451 \item[Difficulty of converting:] simple4452 \item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©.4453 \end{description}4454 4455 \item4456 \begin{description}4457 \item[Change:] make string literals ©const©:4458 \begin{lstlisting}4459 char * p = "abc"; §\C{// valid in C, deprecated in \CFA}§4460 char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§4461 \end{lstlisting}4462 The type of a string literal is changed from ©[] char© to ©const [] char©.4463 Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©.4464 \item[Rationale:] This change is a safety issue:4465 \begin{lstlisting}4466 char * p = "abc";4467 p[0] = 'w'; §\C{// segment fault or change constant literal}§4468 \end{lstlisting}4469 The same problem occurs when passing a string literal to a routine that changes its argument.4470 \item[Effect on original feature:] change to semantics of well-defined feature.4471 \item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©.4472 \item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.4473 \end{description}4474 4475 \item4476 \begin{description}4477 \item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:4478 \begin{lstlisting}4479 int i; §\C{// forward definition}§4480 int *j = ®&i®; §\C{// forward reference, valid in C, invalid in \CFA}§4481 int i = 0; §\C{// definition}§4482 \end{lstlisting}4483 is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.4484 This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example,4485 \begin{lstlisting}4486 struct X { int i; struct X *next; };4487 static struct X a; §\C{// forward definition}§4488 static struct X b = { 0, ®&a® }; §\C{// forward reference, valid in C, invalid in \CFA}§4489 static struct X a = { 1, &b }; §\C{// definition}§4490 \end{lstlisting}4491 \item[Rationale:] avoids having different initialization rules for builtin types and userdefined types.4492 \item[Effect on original feature:] change to semantics of well-defined feature.4493 \item[Difficulty of converting:] the initializer for one of a set of mutually-referential file-local static objects must invoke a routine call to achieve the initialization.4494 \item[How widely used:] seldom4495 \end{description}4496 4497 \item4498 \begin{description}4499 \item[Change:] have ©struct© introduce a scope for nested types:4500 \begin{lstlisting}4501 enum ®Colour® { R, G, B, Y, C, M };4502 struct Person {4503 enum ®Colour® { R, G, B }; §\C{// nested type}§4504 struct Face { §\C{// nested type}§4505 ®Colour® Eyes, Hair; §\C{// type defined outside (1 level)}§4506 };4507 ß.ß®Colour® shirt; §\C{// type defined outside (top level)}§4508 ®Colour® pants; §\C{// type defined same level}§4509 Face looks[10]; §\C{// type defined same level}§4510 };4511 ®Colour® c = R; §\C{// type/enum defined same level}§4512 Personß.ß®Colour® pc = Personß.ßR; §\C{// type/enum defined inside}§4513 Personß.ßFace pretty; §\C{// type defined inside}§4514 \end{lstlisting}4515 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.4516 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.4517 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.4518 \item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism.4519 \item[Effect on original feature:] change to semantics of well-defined feature.4520 \item[Difficulty of converting:] Semantic transformation.4521 \item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.4522 \end{description}4523 4524 \item4525 \begin{description}4526 \item[Change:] In C++, the name of a nested class is local to its enclosing class.4527 \item[Rationale:] C++ classes have member functions which require that classes establish scopes.4528 \item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:4529 \begin{lstlisting}4530 struct Y; §\C{// struct Y and struct X are at the same scope}§4531 struct X {4532 struct Y { /* ... */ } y;4533 };4534 \end{lstlisting}4535 All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct.4536 Note: this is a consequence of the difference in scope rules, which is documented in 3.3.4537 \item[How widely used:] Seldom.4538 \end{description}4539 4540 \item4541 \begin{description}4542 \item[Change:] comma expression is disallowed as subscript4543 \item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new style arrays.4544 \item[Effect on original feature:] change to semantics of well-defined feature.4545 \item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]©4546 \item[How widely used:] seldom.4547 \end{description}4548 \end{enumerate}4549 4550 4551 4371 \section{New Keywords} 4552 4372 \label{s:NewKeywords} 4553 4373 4554 4374 \begin{quote2} 4555 \begin{tabular}{lll} 4556 ©catch© & ©fallthrough© & ©otype© \\ 4557 ©catchResume© & ©fallthru© & ©throw© \\ 4558 ©choose© & ©finally© & ©throwResume© \\ 4559 ©disable© & ©forall© & ©trait© \\ 4560 ©dtype© & ©ftype© & ©try© \\ 4561 ©enable© & ©lvalue© & \\ 4375 \begin{tabular}{ll} 4376 ©catch© & ©lvalue© \\ 4377 ©catchResume© & \\ 4378 ©choose© & ©otype© \\ 4379 & \\ 4380 ©disable© & ©throw© \\ 4381 ©dtype© & ©throwResume© \\ 4382 & ©trait© \\ 4383 ©enable© & ©try© \\ 4384 & \\ 4385 ©fallthrough© \\ 4386 ©fallthru© \\ 4387 ©finally© \\ 4388 ©forall© \\ 4389 ©ftype© \\ 4562 4390 \end{tabular} 4563 4391 \end{quote2} … … 4567 4395 \label{s:StandardHeaders} 4568 4396 4569 C prescribes the following standard header-files ~\cite[\S~7.1.2]{C11}:4397 C prescribes the following standard header-files: 4570 4398 \begin{quote2} 4571 4399 \begin{minipage}{\linewidth} … … 4584 4412 \end{minipage} 4585 4413 \end{quote2} 4586 For the prescribed head-files, \CFA implicit lywraps their includes in an ©extern "C"©;4414 For the prescribed head-files, \CFA implicit wraps their includes in an ©extern "C"©; 4587 4415 hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}). 4588 4416 All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling. 4417 4418 4419 \section{Incompatible} 4420 4421 The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{ANSI14:C++}. 4422 4423 \begin{enumerate} 4424 \item 4425 \begin{description} 4426 \item[Change:] add new keywords (see~\VRef{s:NewKeywords}) \\ 4427 New keywords are added to \CFA. 4428 \item[Rationale:] keywords added to implement new semantics of \CFA. 4429 \item[Effect on original feature:] change to semantics of well-defined feature. \\ 4430 Any ISO C programs using these keywords as identifiers are invalid \CFA programs. 4431 \item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism: 4432 \begin{lstlisting} 4433 int `otype` = 3; // make keyword an identifier 4434 double `choose` = 3.5; 4435 \end{lstlisting} 4436 Programs can be converted automatically by enclosing keyword identifiers in backquotes, and the backquotes can be remove later when the identifier name is changed. 4437 Clashes in C system libraries (include files) can be handled automatically using preprocessor, ©#include_next© and ©-Ifilename©: 4438 \begin{lstlisting} 4439 // include file uses the CFA keyword "otype". 4440 #if ! defined( otype ) // nesting ? 4441 #define otype `otype` 4442 #define __CFA_BFD_H__ 4443 #endif // ! otype 4444 4445 #include_next <bfd.h> // must have internal check for multiple expansion 4446 4447 #if defined( otype ) && defined( __CFA_BFD_H__ ) // reset only if set 4448 #undef otype 4449 #undef __CFA_BFD_H__ 4450 #endif // otype && __CFA_BFD_H__ 4451 \end{lstlisting} 4452 \item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare. 4453 \end{description} 4454 4455 \item 4456 \begin{description} 4457 \item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading: 4458 \begin{lstlisting} 4459 int rtn( int i ); 4460 int rtn( char c ); 4461 rtn( 'x' ); // programmer expects 2nd rtn to be called 4462 \end{lstlisting} 4463 \item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first. 4464 In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character. 4465 \begin{lstlisting} 4466 sout | 'x' | " " | (int)'x' | endl; 4467 x 120 4468 \end{lstlisting} 4469 Having to cast ©'x'© to ©char© is non-intuitive. 4470 \item[Effect on original feature:] change to semantics of well-defined feature that depend on: 4471 \begin{lstlisting} 4472 sizeof( 'x' ) == sizeof( int ) 4473 \end{lstlisting} 4474 no long work the same in \CFA programs. 4475 \item[Difficulty of converting:] simple 4476 \item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©. 4477 \end{description} 4478 4479 \item 4480 \begin{description} 4481 \item[Change:] make string literals ©const©: 4482 \begin{lstlisting} 4483 char * p = "abc"; // valid in C, deprecated in §\CFA§ 4484 char * q = expr ? "abc" : "de"; // valid in C, invalid in §\CFA§ 4485 \end{lstlisting} 4486 The type of a string literal is changed from ©[] char© to ©const [] char©. 4487 Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©. 4488 \item[Rationale:] This change is a safety issue: 4489 \begin{lstlisting} 4490 char * p = "abc"; 4491 p[0] = 'w'; // segment fault or change constant literal 4492 \end{lstlisting} 4493 The same problem occurs when passing a string literal to a routine that changes its argument. 4494 \item[Effect on original feature:] change to semantics of well-defined feature. 4495 \item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©. 4496 \item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare. 4497 \end{description} 4498 4499 \item 4500 \begin{description} 4501 \item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope: 4502 \begin{lstlisting} 4503 int i; // forward definition 4504 int *j = ®&i®; // forward reference, valid in C, invalid in §\CFA§ 4505 int i = 0; // definition 4506 \end{lstlisting} 4507 is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed. 4508 This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example, 4509 \begin{lstlisting} 4510 struct X { int i; struct X *next; }; 4511 static struct X a; // forward definition 4512 static struct X b = { 0, ®&a® }; // forward reference, valid in C, invalid in §\CFA§ 4513 static struct X a = { 1, &b }; // definition 4514 \end{lstlisting} 4515 \item[Rationale:] avoids having different initialization rules for builtin types and userdefined types. 4516 \item[Effect on original feature:] change to semantics of well-defined feature. 4517 \item[Difficulty of converting:] the initializer for one of a set of mutually-referential file-local static objects must invoke a routine call to achieve the initialization. 4518 \item[How widely used:] seldom 4519 \end{description} 4520 4521 \item 4522 \begin{description} 4523 \item[Change:] have ©struct© introduce a scope for nested types 4524 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing 4525 Example: 4526 \begin{lstlisting} 4527 enum ®Colour® { R, G, B, Y, C, M }; 4528 struct Person { 4529 enum ®Colour® { R, G, B }; // nested type 4530 struct Face { // nested type 4531 ®Colour® Eyes, Hair; // type defined outside (1 level) 4532 }; 4533 ß.ß®Colour® shirt; // type defined outside (top level) 4534 ®Colour® pants; // type defined same level 4535 Face looks[10]; // type defined same level 4536 }; 4537 ®Colour® c = R; // type/enum defined same level 4538 Personß.ß®Colour® pc = Personß.ßR; // type/enum defined inside 4539 Personß.ßFace pretty; // type defined inside 4540 \end{lstlisting} 4541 \item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism. 4542 \item[Effect on original feature:] change to semantics of well-defined feature. 4543 \item[Difficulty of converting:] Semantic transformation. 4544 \item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version. 4545 4546 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}. 4547 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''. 4548 Given that nested types in C are equivalent to not using them, \ie they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility. 4549 \end{description} 4550 4551 \item 4552 \begin{description} 4553 \item[Change:] In C++, the name of a nested class is local to its enclosing class. 4554 \item[Rationale:] C++ classes have member functions which require that classes establish scopes. 4555 \item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example: 4556 \begin{lstlisting} 4557 struct Y; // struct Y and struct X are at the same scope 4558 struct X { 4559 struct Y { /* ... */ } y; 4560 }; 4561 \end{lstlisting} 4562 All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct. 4563 Note: this is a consequence of the difference in scope rules, which is documented in 3.3. 4564 \item[How widely used:] Seldom. 4565 \end{description} 4566 4567 \item 4568 \begin{description} 4569 \item[Change:] comma expression is disallowed as subscript 4570 \item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new style arrays. 4571 \item[Effect on original feature:] change to semantics of well-defined feature. 4572 \item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]© 4573 \item[How widely used:] seldom. 4574 \end{description} 4575 \end{enumerate} 4589 4576 4590 4577 … … 4762 4749 \subsection{malloc} 4763 4750 4764 \leavevmode4765 4751 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4766 4752 forall( otype T ) T * malloc( void );§\indexc{malloc}§ … … 4779 4765 forall( otype T ) T * memset( T * ptr ); // remove when default value available 4780 4766 \end{lstlisting} 4781 4767 \ 4782 4768 4783 4769 \subsection{ato / strto} 4784 4770 4785 \leavevmode4786 4771 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4787 4772 int ato( const char * ptr );§\indexc{ato}§ … … 4811 4796 long double _Complex strto( const char * sptr, char ** eptr ); 4812 4797 \end{lstlisting} 4798 \ 4813 4799 4814 4800 4815 4801 \subsection{bsearch / qsort} 4816 4802 4817 \leavevmode4818 4803 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4819 4804 forall( otype T | { int ?<?( T, T ); } ) … … 4823 4808 void qsort( const T * arr, size_t dimension );§\indexc{qsort}§ 4824 4809 \end{lstlisting} 4810 \ 4825 4811 4826 4812 4827 4813 \subsection{abs} 4828 4814 4829 \leavevmode4830 4815 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4831 4816 char abs( char );§\indexc{abs}§ … … 4840 4825 long double abs( long double _Complex ); 4841 4826 \end{lstlisting} 4827 \ 4842 4828 4843 4829 4844 4830 \subsection{random} 4845 4831 4846 \leavevmode4847 4832 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4848 4833 void rand48seed( long int s );§\indexc{rand48seed}§ … … 4858 4843 long double _Complex rand48(); 4859 4844 \end{lstlisting} 4845 \ 4860 4846 4861 4847 4862 4848 \subsection{min / max / clamp / swap} 4863 4849 4864 \leavevmode4865 4850 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4866 4851 forall( otype T | { int ?<?( T, T ); } ) … … 4876 4861 void swap( T * t1, T * t2 );§\indexc{swap}§ 4877 4862 \end{lstlisting} 4863 \ 4878 4864 4879 4865 … … 4886 4872 \subsection{General} 4887 4873 4888 \leavevmode4889 4874 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4890 4875 float fabs( float );§\indexc{fabs}§ … … 4932 4917 long double nan( const char * ); 4933 4918 \end{lstlisting} 4919 \ 4934 4920 4935 4921 4936 4922 \subsection{Exponential} 4937 4923 4938 \leavevmode4939 4924 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4940 4925 float exp( float );§\indexc{exp}§ … … 4989 4974 long double logb( long double ); 4990 4975 \end{lstlisting} 4976 \ 4991 4977 4992 4978 4993 4979 \subsection{Power} 4994 4980 4995 \leavevmode4996 4981 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4997 4982 float sqrt( float );§\indexc{sqrt}§ … … 5017 5002 long double _Complex pow( long double _Complex, long double _Complex ); 5018 5003 \end{lstlisting} 5004 \ 5019 5005 5020 5006 5021 5007 \subsection{Trigonometric} 5022 5008 5023 \leavevmode5024 5009 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5025 5010 float sin( float );§\indexc{sin}§ … … 5073 5058 long double atan( long double, long double ); 5074 5059 \end{lstlisting} 5060 \ 5075 5061 5076 5062 5077 5063 \subsection{Hyperbolic} 5078 5064 5079 \leavevmode5080 5065 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5081 5066 float sinh( float );§\indexc{sinh}§ … … 5121 5106 long double _Complex atanh( long double _Complex ); 5122 5107 \end{lstlisting} 5108 \ 5123 5109 5124 5110 5125 5111 \subsection{Error / Gamma} 5126 5112 5127 \leavevmode5128 5113 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5129 5114 float erf( float );§\indexc{erf}§ … … 5152 5137 long double tgamma( long double ); 5153 5138 \end{lstlisting} 5139 \ 5154 5140 5155 5141 5156 5142 \subsection{Nearest Integer} 5157 5143 5158 \leavevmode5159 5144 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5160 5145 float floor( float );§\indexc{floor}§ … … 5206 5191 long long int llround( long double ); 5207 5192 \end{lstlisting} 5193 \ 5208 5194 5209 5195 5210 5196 \subsection{Manipulation} 5211 5197 5212 \leavevmode5213 5198 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5214 5199 float copysign( float, float );§\indexc{copysign}§ … … 5247 5232 long double scalbln( long double, long int ); 5248 5233 \end{lstlisting} 5234 \ 5249 5235 5250 5236
Note:
See TracChangeset
for help on using the changeset viewer.
