Changeset bf1a2bf for doc/user/user.tex
- Timestamp:
- Aug 14, 2016, 8:26:06 AM (8 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- 46b4259
- Parents:
- 1ca15c1
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/user/user.tex
r1ca15c1 rbf1a2bf 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Tue Aug 2 17:39:02201614 %% Update Count : 1 28613 %% Last Modified On : Sun Aug 14 08:23:06 2016 14 %% Update Count : 1323 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 317 317 318 318 \item 319 \Indexc{-no-include-std }\index{compilation option!-no-include-std@©-no-include-std©}319 \Indexc{-no-include-stdhdr}\index{compilation option!-no-include-stdhdr@©-no-include-stdhdr©} 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 identifier 815 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 // ! otype 825 826 #include_next <bfd.h> // must have internal check for multiple expansion 827 828 #if defined( otype ) && defined( __CFA_BFD_H__ ) // reset only if set 829 #undef otype 830 #undef __CFA_BFD_H__ 831 #endif // otype && __CFA_BFD_H__ 832 \end{lstlisting} 833 834 809 835 \section{Type Operators} 810 836 … … 1011 1037 Alternatively, prototype definitions can be eliminated by using a two-pass compilation, and implicitly creating header files for exports. 1012 1038 The former is easy to do, while the latter is more complex. 1013 Currently, \CFA does \emph{not} attempt to support named arguments. 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. 1014 1057 1015 1058 \item[Default Arguments] … … 1021 1064 the allowable positional calls are: 1022 1065 \begin{lstlisting} 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 )}§1066 p(); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ 1067 p( 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§ 1068 p( 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§ 1069 p( 4, 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§ 1027 1070 // empty arguments 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 )}§1071 p( , 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§ 1072 p( 4, , 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§ 1073 p( 4, 4, ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§ 1074 p( 4, , ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§ 1075 p( , 4, ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§ 1076 p( , , 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§ 1077 p( , , ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ 1035 1078 \end{lstlisting} 1036 1079 Here the missing arguments are inserted from the default values in the parameter list. … … 1067 1110 The conflict occurs because both named and ellipse arguments must appear after positional arguments, giving two possibilities: 1068 1111 \begin{lstlisting} 1069 p( /* positional */, . . ., /* named */ );1070 p( /* positional */, /* named */, . .. );1112 p( /* positional */, ... , /* named */ ); 1113 p( /* positional */, /* named */, ... ); 1071 1114 \end{lstlisting} 1072 1115 While it is possible to implement both approaches, the first possibly is more complex than the second, \eg: 1073 1116 \begin{lstlisting} 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 */, . .. );}§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 */, ... );}§ 1077 1120 \end{lstlisting} 1078 1121 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. … … 1082 1125 The problem is exacerbated with default arguments, \eg: 1083 1126 \begin{lstlisting} 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 */, . .. );}§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 */, ... );}§ 1087 1130 \end{lstlisting} 1088 1131 The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments; … … 1129 1172 \subsection{Type Nesting} 1130 1173 1131 \CFA allows \Index{type nesting}, and type qualification of the nested typ es (see \VRef[Figure]{f:TypeNestingQualification}), where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification.1174 \CFA allows \Index{type nesting}, and type qualification of the nested typres (see \VRef[Figure]{f:TypeNestingQualification}), where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification. 1132 1175 \begin{figure} 1176 \centering 1133 1177 \begin{tabular}{@{}l@{\hspace{3em}}l|l@{}} 1134 1178 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}} & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}} & \multicolumn{1}{|c}{\textbf{\CFA}} \\ … … 1397 1441 Mass assignment has the following form: 1398 1442 \begin{lstlisting} 1399 [ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§;1443 [ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§; 1400 1444 \end{lstlisting} 1401 1445 \index{lvalue} … … 1437 1481 Multiple assignment has the following form: 1438 1482 \begin{lstlisting} 1439 [ §\emph{lvalue}§, . . ., §\emph{lvalue}§ ] = [ §\emph{expr}§, . . ., §\emph{expr}§ ];1483 [ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ]; 1440 1484 \end{lstlisting} 1441 1485 \index{lvalue} … … 1873 1917 \begin{lstlisting} 1874 1918 switch ( i ) { 1875 ®case1, 3, 5®:1919 case ®1, 3, 5®: 1876 1920 ... 1877 ®case2, 4, 6®:1921 case ®2, 4, 6®: 1878 1922 ... 1879 1923 } … … 1906 1950 \begin{lstlisting} 1907 1951 switch ( i ) { 1908 ®case1~5:®1952 case ®1~5:® 1909 1953 ... 1910 ®case10~15:®1954 case ®10~15:® 1911 1955 ... 1912 1956 } … … 1915 1959 \begin{lstlisting} 1916 1960 switch ( i ) 1917 case 1 ... 5:1961 case ®1 ... 5®: 1918 1962 ... 1919 case 10 ... 15:1963 case ®10 ... 15®: 1920 1964 ... 1921 1965 } … … 4369 4413 4370 4414 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 \item 4421 \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 \item 4432 \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 120 4444 \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:] simple 4452 \item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©. 4453 \end{description} 4454 4455 \item 4456 \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 \item 4476 \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:] seldom 4495 \end{description} 4496 4497 \item 4498 \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 \item 4525 \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 \item 4541 \begin{description} 4542 \item[Change:] comma expression is disallowed as subscript 4543 \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 4371 4551 \section{New Keywords} 4372 4552 \label{s:NewKeywords} 4373 4553 4374 4554 \begin{quote2} 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© \\ 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© & \\ 4390 4562 \end{tabular} 4391 4563 \end{quote2} … … 4395 4567 \label{s:StandardHeaders} 4396 4568 4397 C prescribes the following standard header-files :4569 C prescribes the following standard header-files~\cite[\S~7.1.2]{C11}: 4398 4570 \begin{quote2} 4399 4571 \begin{minipage}{\linewidth} … … 4412 4584 \end{minipage} 4413 4585 \end{quote2} 4414 For the prescribed head-files, \CFA implicit wraps their includes in an ©extern "C"©;4586 For the prescribed head-files, \CFA implicitly wraps their includes in an ©extern "C"©; 4415 4587 hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}). 4416 4588 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 \item4425 \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 identifier4434 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 // ! otype4444 4445 #include_next <bfd.h> // must have internal check for multiple expansion4446 4447 #if defined( otype ) && defined( __CFA_BFD_H__ ) // reset only if set4448 #undef otype4449 #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 \item4456 \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 called4462 \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 1204468 \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:] simple4476 \item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©.4477 \end{description}4478 4479 \item4480 \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 literal4492 \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 \item4500 \begin{description}4501 \item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:4502 \begin{lstlisting}4503 int i; // forward definition4504 int *j = ®&i®; // forward reference, valid in C, invalid in §\CFA§4505 int i = 0; // definition4506 \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 definition4512 static struct X b = { 0, ®&a® }; // forward reference, valid in C, invalid in §\CFA§4513 static struct X a = { 1, &b }; // definition4514 \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:] seldom4519 \end{description}4520 4521 \item4522 \begin{description}4523 \item[Change:] have ©struct© introduce a scope for nested types4524 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing4525 Example:4526 \begin{lstlisting}4527 enum ®Colour® { R, G, B, Y, C, M };4528 struct Person {4529 enum ®Colour® { R, G, B }; // nested type4530 struct Face { // nested type4531 ®Colour® Eyes, Hair; // type defined outside (1 level)4532 };4533 ß.ß®Colour® shirt; // type defined outside (top level)4534 ®Colour® pants; // type defined same level4535 Face looks[10]; // type defined same level4536 };4537 ®Colour® c = R; // type/enum defined same level4538 Personß.ß®Colour® pc = Personß.ßR; // type/enum defined inside4539 Personß.ßFace pretty; // type defined inside4540 \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 \item4552 \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 scope4558 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 \item4568 \begin{description}4569 \item[Change:] comma expression is disallowed as subscript4570 \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}4576 4589 4577 4590 … … 4749 4762 \subsection{malloc} 4750 4763 4764 \leavevmode 4751 4765 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4752 4766 forall( otype T ) T * malloc( void );§\indexc{malloc}§ … … 4765 4779 forall( otype T ) T * memset( T * ptr ); // remove when default value available 4766 4780 \end{lstlisting} 4767 \ 4781 4768 4782 4769 4783 \subsection{ato / strto} 4770 4784 4785 \leavevmode 4771 4786 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4772 4787 int ato( const char * ptr );§\indexc{ato}§ … … 4796 4811 long double _Complex strto( const char * sptr, char ** eptr ); 4797 4812 \end{lstlisting} 4798 \4799 4813 4800 4814 4801 4815 \subsection{bsearch / qsort} 4802 4816 4817 \leavevmode 4803 4818 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4804 4819 forall( otype T | { int ?<?( T, T ); } ) … … 4808 4823 void qsort( const T * arr, size_t dimension );§\indexc{qsort}§ 4809 4824 \end{lstlisting} 4810 \4811 4825 4812 4826 4813 4827 \subsection{abs} 4814 4828 4829 \leavevmode 4815 4830 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4816 4831 char abs( char );§\indexc{abs}§ … … 4825 4840 long double abs( long double _Complex ); 4826 4841 \end{lstlisting} 4827 \4828 4842 4829 4843 4830 4844 \subsection{random} 4831 4845 4846 \leavevmode 4832 4847 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4833 4848 void rand48seed( long int s );§\indexc{rand48seed}§ … … 4843 4858 long double _Complex rand48(); 4844 4859 \end{lstlisting} 4845 \4846 4860 4847 4861 4848 4862 \subsection{min / max / clamp / swap} 4849 4863 4864 \leavevmode 4850 4865 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4851 4866 forall( otype T | { int ?<?( T, T ); } ) … … 4861 4876 void swap( T * t1, T * t2 );§\indexc{swap}§ 4862 4877 \end{lstlisting} 4863 \4864 4878 4865 4879 … … 4872 4886 \subsection{General} 4873 4887 4888 \leavevmode 4874 4889 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4875 4890 float fabs( float );§\indexc{fabs}§ … … 4917 4932 long double nan( const char * ); 4918 4933 \end{lstlisting} 4919 \4920 4934 4921 4935 4922 4936 \subsection{Exponential} 4923 4937 4938 \leavevmode 4924 4939 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4925 4940 float exp( float );§\indexc{exp}§ … … 4974 4989 long double logb( long double ); 4975 4990 \end{lstlisting} 4976 \4977 4991 4978 4992 4979 4993 \subsection{Power} 4980 4994 4995 \leavevmode 4981 4996 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4982 4997 float sqrt( float );§\indexc{sqrt}§ … … 5002 5017 long double _Complex pow( long double _Complex, long double _Complex ); 5003 5018 \end{lstlisting} 5004 \5005 5019 5006 5020 5007 5021 \subsection{Trigonometric} 5008 5022 5023 \leavevmode 5009 5024 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5010 5025 float sin( float );§\indexc{sin}§ … … 5058 5073 long double atan( long double, long double ); 5059 5074 \end{lstlisting} 5060 \5061 5075 5062 5076 5063 5077 \subsection{Hyperbolic} 5064 5078 5079 \leavevmode 5065 5080 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5066 5081 float sinh( float );§\indexc{sinh}§ … … 5106 5121 long double _Complex atanh( long double _Complex ); 5107 5122 \end{lstlisting} 5108 \5109 5123 5110 5124 5111 5125 \subsection{Error / Gamma} 5112 5126 5127 \leavevmode 5113 5128 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5114 5129 float erf( float );§\indexc{erf}§ … … 5137 5152 long double tgamma( long double ); 5138 5153 \end{lstlisting} 5139 \5140 5154 5141 5155 5142 5156 \subsection{Nearest Integer} 5143 5157 5158 \leavevmode 5144 5159 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5145 5160 float floor( float );§\indexc{floor}§ … … 5191 5206 long long int llround( long double ); 5192 5207 \end{lstlisting} 5193 \5194 5208 5195 5209 5196 5210 \subsection{Manipulation} 5197 5211 5212 \leavevmode 5198 5213 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5199 5214 float copysign( float, float );§\indexc{copysign}§ … … 5232 5247 long double scalbln( long double, long int ); 5233 5248 \end{lstlisting} 5234 \5235 5249 5236 5250
Note: See TracChangeset
for help on using the changeset viewer.