Changeset 917ab04 for doc/user/user.tex
- Timestamp:
- May 21, 2017, 11:24:35 PM (7 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- 0ed8759
- Parents:
- 88e0080
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/user/user.tex
r88e0080 r917ab04 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Fri May 19 11:54:31201714 %% Update Count : 1 73513 %% Last Modified On : Sun May 21 23:16:45 2017 14 %% Update Count : 1817 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 94 94 \author{ 95 95 \huge \CFA Team \medskip \\ 96 \Large Richard Bilson, Peter A. Buhr, Thierry Delisle, \smallskip \\96 \Large Andrew Beach, Richard Bilson, Peter A. Buhr, Thierry Delisle, \smallskip \\ 97 97 \Large Glen Ditchfield, Rodolfo G. Esteves, Aaron Moss, Rob Schluntz 98 98 }% author … … 644 644 \end{quote2} 645 645 646 Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified,\footnote{ 647 At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}} 648 \eg: 649 \begin{cfa} 650 x; §\C{// int x}§ 651 *y; §\C{// int *y}§ 652 f( p1, p2 ); §\C{// int f( int p1, int p2 );}§ 653 f( p1, p2 ) {} §\C{// int f( int p1, int p2 ) {}}§ 654 \end{cfa} 646 The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©: 647 \begin{quote2} 648 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 649 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 650 \begin{cfa} 651 y = (®* int®)x; 652 i = sizeof(®[ 5 ] * int®); 653 \end{cfa} 654 & 655 \begin{cfa} 656 y = (®int *®)x; 657 i = sizeof(®int *[ 5 ]®); 658 \end{cfa} 659 \end{tabular} 660 \end{quote2} 655 661 656 662 Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration. … … 1105 1111 > already. 1106 1112 \end{comment} 1107 1108 1109 \section{Type Operators}1110 1111 The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©:1112 \begin{quote2}1113 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}1114 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\1115 \begin{cfa}1116 y = (®* int®)x;1117 i = sizeof(®[ 5 ] * int®);1118 \end{cfa}1119 &1120 \begin{cfa}1121 y = (®int *®)x;1122 i = sizeof(®int *[ 5 ]®);1123 \end{cfa}1124 \end{tabular}1125 \end{quote2}1126 1113 1127 1114 … … 4842 4829 4843 4830 4844 \section{Syntactic Anomalies} 4845 4846 There are several ambiguous cases with operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©~\R{/}~©?*?© or ©*?©~\R{/}~©*?©. 4847 Since it is common practise to put a unary operator juxtaposed to an identifier, \eg ©*i©, users will be annoyed if they cannot do this with respect to operator identifiers. 4848 Even with this special hack, there are 5 general cases that cannot be handled. 4849 The first case is for the function-call identifier ©?()©: 4850 \begin{cfa} 4851 int *§\textvisiblespace§?()(); // declaration: space required after '*' 4852 *§\textvisiblespace§?()(); // expression: space required after '*' 4853 \end{cfa} 4854 Without the space, the string ©*?()© is ambiguous without N character look ahead; 4855 it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument/parameter list. 4856 4857 The 4 remaining cases occur in expressions: 4858 \begin{cfa} 4859 i++§\textvisiblespace§?i:0; // space required before '?' 4860 i--§\textvisiblespace§?i:0; // space required before '?' 4861 i§\textvisiblespace§?++i:0; // space required after '?' 4862 i§\textvisiblespace§?--i:0; // space required after '?' 4863 \end{cfa} 4864 In the first two cases, the string ©i++?© is ambiguous, where this string can be lexed as ©i© / ©++?© or ©i++© / ©?©; 4865 it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list. 4866 In the second two cases, the string ©?++x© is ambiguous, where this string can be lexed as ©?++© / ©x© or ©?© / y©++x©; 4867 it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list. 4868 4869 4870 \section{Incompatible} 4871 4872 The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{C++14}. 4873 4874 \begin{enumerate} 4875 \item 4876 \begin{description} 4877 \item[Change:] add new keywords \\ 4878 New keywords are added to \CFA (see~\VRef{s:NewKeywords}). 4879 \item[Rationale:] keywords added to implement new semantics of \CFA. 4880 \item[Effect on original feature:] change to semantics of well-defined feature. \\ 4881 Any ISO C programs using these keywords as identifiers are invalid \CFA programs. 4882 \item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}): 4883 \item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare. 4884 \end{description} 4885 4886 \item 4887 \begin{description} 4888 \item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading: 4889 \begin{cfa} 4890 int rtn( int i ); 4891 int rtn( char c ); 4892 rtn( 'x' ); §\C{// programmer expects 2nd rtn to be called}§ 4893 \end{cfa} 4894 \item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first. 4895 In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character. 4896 \begin{cfa} 4897 sout | 'x' | " " | (int)'x' | endl; 4898 x 120 4899 \end{cfa} 4900 Having to cast ©'x'© to ©char© is non-intuitive. 4901 \item[Effect on original feature:] change to semantics of well-defined feature that depend on: 4902 \begin{cfa} 4903 sizeof( 'x' ) == sizeof( int ) 4904 \end{cfa} 4905 no long work the same in \CFA programs. 4906 \item[Difficulty of converting:] simple 4907 \item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©. 4908 \end{description} 4909 4910 \item 4911 \begin{description} 4912 \item[Change:] make string literals ©const©: 4913 \begin{cfa} 4914 char * p = "abc"; §\C{// valid in C, deprecated in \CFA}§ 4915 char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§ 4916 \end{cfa} 4917 The type of a string literal is changed from ©[] char© to ©const [] char©. 4918 Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©. 4919 \item[Rationale:] This change is a safety issue: 4920 \begin{cfa} 4921 char * p = "abc"; 4922 p[0] = 'w'; §\C{// segment fault or change constant literal}§ 4923 \end{cfa} 4924 The same problem occurs when passing a string literal to a routine that changes its argument. 4925 \item[Effect on original feature:] change to semantics of well-defined feature. 4926 \item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©. 4927 \item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare. 4928 \end{description} 4929 4930 \item 4931 \begin{description} 4932 \item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope: 4933 \begin{cfa} 4934 int i; §\C{// forward definition}§ 4935 int *j = ®&i®; §\C{// forward reference, valid in C, invalid in \CFA}§ 4936 int i = 0; §\C{// definition}§ 4937 \end{cfa} 4938 is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed. 4939 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, 4940 \begin{cfa} 4941 struct X { int i; struct X *next; }; 4942 static struct X a; §\C{// forward definition}§ 4943 static struct X b = { 0, ®&a® }; §\C{// forward reference, valid in C, invalid in \CFA}§ 4944 static struct X a = { 1, &b }; §\C{// definition}§ 4945 \end{cfa} 4946 \item[Rationale:] avoids having different initialization rules for builtin types and userdefined types. 4947 \item[Effect on original feature:] change to semantics of well-defined feature. 4948 \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. 4949 \item[How widely used:] seldom 4950 \end{description} 4951 4952 \item 4953 \begin{description} 4954 \item[Change:] have ©struct© introduce a scope for nested types: 4955 \begin{cfa} 4956 enum ®Colour® { R, G, B, Y, C, M }; 4957 struct Person { 4958 enum ®Colour® { R, G, B }; §\C{// nested type}§ 4959 struct Face { §\C{// nested type}§ 4960 ®Colour® Eyes, Hair; §\C{// type defined outside (1 level)}§ 4961 }; 4962 ß.ß®Colour® shirt; §\C{// type defined outside (top level)}§ 4963 ®Colour® pants; §\C{// type defined same level}§ 4964 Face looks[10]; §\C{// type defined same level}§ 4965 }; 4966 ®Colour® c = R; §\C{// type/enum defined same level}§ 4967 Personß.ß®Colour® pc = Personß.ßR; §\C{// type/enum defined inside}§ 4968 Personß.ßFace pretty; §\C{// type defined inside}§ 4969 \end{cfa} 4970 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, \ie the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing. 4971 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}. 4972 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''. 4973 \item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism. 4974 \item[Effect on original feature:] change to semantics of well-defined feature. 4975 \item[Difficulty of converting:] Semantic transformation. 4976 \item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version. 4977 \end{description} 4978 4979 \item 4980 \begin{description} 4981 \item[Change:] In C++, the name of a nested class is local to its enclosing class. 4982 \item[Rationale:] C++ classes have member functions which require that classes establish scopes. 4983 \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: 4984 \begin{cfa} 4985 struct Y; §\C{// struct Y and struct X are at the same scope}§ 4986 struct X { 4987 struct Y { /* ... */ } y; 4988 }; 4989 \end{cfa} 4990 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. 4991 Note: this is a consequence of the difference in scope rules, which is documented in 3.3. 4992 \item[How widely used:] Seldom. 4993 \end{description} 4994 4995 \item 4996 \begin{description} 4997 \item[Change:] comma expression is disallowed as subscript 4998 \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. 4999 \item[Effect on original feature:] change to semantics of well-defined feature. 5000 \item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]© 5001 \item[How widely used:] seldom. 5002 \end{description} 5003 \end{enumerate} 4831 \section{Syntax Ambiguities} 4832 4833 C has a number of syntax ambiguities, which are resolved by taking the longest sequence of overlapping characters that constitute a token. 4834 For example, the program fragment ©x+++++y© is parsed as \lstinline[showspaces=true]@x ++ ++ + y@ because operator tokens ©++© and ©+© overlap. 4835 Unfortunately, the longest sequence violates a constraint on increment operators, even though the parse \lstinline[showspaces=true]@x ++ + ++ y@ might yield a correct expression. 4836 Hence, C programmers are aware that spaces have to added to disambiguate certain syntactic cases. 4837 4838 In \CFA, there are ambiguous cases with dereference and operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be interpreted as: 4839 \begin{cfa} 4840 *?§\color{red}\textvisiblespace§*? 4841 *§\color{red}\textvisiblespace§?*? 4842 \end{cfa} 4843 By default, the first interpretation is selected, which does not yield a meaningful string in the language. 4844 Therefore, \CFA does a lexical look-ahead for the second case, and backtracks to return the leading unary operator and reparses the trailing operator identifier. 4845 Otherwise a space is needed between the unary operator and operator identifier to disambiguate this common case. 4846 4847 A similar issue occurs with the dereference, ©*?(...)©, and routine-call, ©?()(...)© identifiers. 4848 The ambiguity occurs when the deference operator has no parameters: 4849 \begin{cfa} 4850 *?()§\color{red}\textvisiblespace...§ ; 4851 *?()§\color{red}\textvisiblespace...§(...) ; 4852 \end{cfa} 4853 requiring arbitrary whitespace look-ahead for the routine-call parameter list to disambiguate. 4854 However, the dereference operator \emph{must} have a parameter/argument to dereference ©*?(...)©. 4855 Hence, always interpreting the string ©*?()© as \lstinline[showspaces=true]@* ?()@ does not preclude any meaningful program. 4856 4857 The remaining cases are with the increment/decrement operators and conditional expression, \eg: 4858 \begin{cfa} 4859 i++?§\color{red}\textvisiblespace...§(...); 4860 i?++§\color{red}\textvisiblespace...§(...); 4861 \end{cfa} 4862 requiring arbitrary whitespace look-ahead for the routine-call parameter list, even though that interpretation is an incorrect expression (juxtaposed identifiers). 4863 Therefore, it is necessary to disambiguate these cases with a space: 4864 \begin{cfa} 4865 i++§\color{red}\textvisiblespace§? i : 0; 4866 i?§\color{red}\textvisiblespace§++i : 0; 4867 \end{cfa} 5004 4868 5005 4869 … … 5008 4872 5009 4873 \begin{quote2} 5010 \begin{tabular}{lll }4874 \begin{tabular}{llll} 5011 4875 \begin{tabular}{@{}l@{}} 5012 4876 ©_AT© \\ … … 5016 4880 ©coroutine© \\ 5017 4881 ©disable© \\ 5018 ©dtype© \\5019 ©enable© \\5020 4882 \end{tabular} 5021 4883 & 5022 4884 \begin{tabular}{@{}l@{}} 4885 ©dtype© \\ 4886 ©enable© \\ 5023 4887 ©fallthrough© \\ 5024 4888 ©fallthru© \\ 5025 4889 ©finally© \\ 5026 4890 ©forall© \\ 4891 \end{tabular} 4892 & 4893 \begin{tabular}{@{}l@{}} 5027 4894 ©ftype© \\ 5028 4895 ©lvalue© \\ 5029 4896 ©monitor© \\ 5030 4897 ©mutex© \\ 4898 ©one_t© \\ 4899 ©otype© \\ 5031 4900 \end{tabular} 5032 4901 & 5033 4902 \begin{tabular}{@{}l@{}} 5034 ©one_t© \\5035 ©otype© \\5036 4903 ©throw© \\ 5037 4904 ©throwResume© \\ … … 5043 4910 \end{tabular} 5044 4911 \end{quote2} 4912 4913 4914 \section{Incompatible} 4915 4916 The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{C++14}. 4917 4918 4919 \begin{enumerate} 4920 \item 4921 \begin{description} 4922 \item[Change:] add new keywords \\ 4923 New keywords are added to \CFA (see~\VRef{s:CFAKeywords}). 4924 \item[Rationale:] keywords added to implement new semantics of \CFA. 4925 \item[Effect on original feature:] change to semantics of well-defined feature. \\ 4926 Any ISO C programs using these keywords as identifiers are invalid \CFA programs. 4927 \item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}). 4928 \item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare. 4929 \end{description} 4930 4931 \item 4932 \begin{description} 4933 \item[Change:] drop K\&R C declarations \\ 4934 K\&R declarations allow an implicit base-type of ©int©, if no type is specified, plus an alternate syntax for declaring parameters. 4935 \eg: 4936 \begin{cfa} 4937 x; §\C{// int x}§ 4938 *y; §\C{// int *y}§ 4939 f( p1, p2 ); §\C{// int f( int p1, int p2 );}§ 4940 g( p1, p2 ) int p1, p2; §\C{// int g( int p1, int p2 );}§ 4941 \end{cfa} 4942 \CFA supports K\&R routine definitions: 4943 \begin{cfa} 4944 f( a, b, c ) §\C{// default int return}§ 4945 int a, b; char c §\C{// K\&R parameter declarations}§ 4946 { 4947 ... 4948 } 4949 \end{cfa} 4950 \item[Rationale:] dropped from C11 standard.\footnote{ 4951 At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}} 4952 \item[Effect on original feature:] original feature is deprecated. \\ 4953 Any old C programs using these K\&R declarations are invalid \CFA programs. 4954 \item[Difficulty of converting:] trivial to convert to \CFA. 4955 \item[How widely used:] existing usages are rare. 4956 \end{description} 4957 4958 \item 4959 \begin{description} 4960 \item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading: 4961 \begin{cfa} 4962 int rtn( int i ); 4963 int rtn( char c ); 4964 rtn( 'x' ); §\C{// programmer expects 2nd rtn to be called}§ 4965 \end{cfa} 4966 \item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first. 4967 In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character. 4968 \begin{cfa} 4969 sout | 'x' | " " | (int)'x' | endl; 4970 x 120 4971 \end{cfa} 4972 Having to cast ©'x'© to ©char© is non-intuitive. 4973 \item[Effect on original feature:] change to semantics of well-defined feature that depend on: 4974 \begin{cfa} 4975 sizeof( 'x' ) == sizeof( int ) 4976 \end{cfa} 4977 no long work the same in \CFA programs. 4978 \item[Difficulty of converting:] simple 4979 \item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©. 4980 \end{description} 4981 4982 \item 4983 \begin{description} 4984 \item[Change:] make string literals ©const©: 4985 \begin{cfa} 4986 char * p = "abc"; §\C{// valid in C, deprecated in \CFA}§ 4987 char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§ 4988 \end{cfa} 4989 The type of a string literal is changed from ©[] char© to ©const [] char©. 4990 Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©. 4991 \item[Rationale:] This change is a safety issue: 4992 \begin{cfa} 4993 char * p = "abc"; 4994 p[0] = 'w'; §\C{// segment fault or change constant literal}§ 4995 \end{cfa} 4996 The same problem occurs when passing a string literal to a routine that changes its argument. 4997 \item[Effect on original feature:] change to semantics of well-defined feature. 4998 \item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©. 4999 \item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare. 5000 \end{description} 5001 5002 \item 5003 \begin{description} 5004 \item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope: 5005 \begin{cfa} 5006 int i; §\C{// forward definition}§ 5007 int *j = ®&i®; §\C{// forward reference, valid in C, invalid in \CFA}§ 5008 int i = 0; §\C{// definition}§ 5009 \end{cfa} 5010 is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed. 5011 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, 5012 \begin{cfa} 5013 struct X { int i; struct X *next; }; 5014 static struct X a; §\C{// forward definition}§ 5015 static struct X b = { 0, ®&a® }; §\C{// forward reference, valid in C, invalid in \CFA}§ 5016 static struct X a = { 1, &b }; §\C{// definition}§ 5017 \end{cfa} 5018 \item[Rationale:] avoids having different initialization rules for builtin types and userdefined types. 5019 \item[Effect on original feature:] change to semantics of well-defined feature. 5020 \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. 5021 \item[How widely used:] seldom 5022 \end{description} 5023 5024 \item 5025 \begin{description} 5026 \item[Change:] have ©struct© introduce a scope for nested types: 5027 \begin{cfa} 5028 enum ®Colour® { R, G, B, Y, C, M }; 5029 struct Person { 5030 enum ®Colour® { R, G, B }; §\C{// nested type}§ 5031 struct Face { §\C{// nested type}§ 5032 ®Colour® Eyes, Hair; §\C{// type defined outside (1 level)}§ 5033 }; 5034 ®.Colour® shirt; §\C{// type defined outside (top level)}§ 5035 ®Colour® pants; §\C{// type defined same level}§ 5036 Face looks[10]; §\C{// type defined same level}§ 5037 }; 5038 ®Colour® c = R; §\C{// type/enum defined same level}§ 5039 Person®.Colour® pc = Person®.®R; §\C{// type/enum defined inside}§ 5040 Person®.®Face pretty; §\C{// type defined inside}§ 5041 \end{cfa} 5042 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, \ie the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing. 5043 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}. 5044 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''. 5045 \item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism. 5046 \item[Effect on original feature:] change to semantics of well-defined feature. 5047 \item[Difficulty of converting:] Semantic transformation. 5048 \item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version. 5049 \end{description} 5050 5051 \item 5052 \begin{description} 5053 \item[Change:] In C++, the name of a nested class is local to its enclosing class. 5054 \item[Rationale:] C++ classes have member functions which require that classes establish scopes. 5055 \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: 5056 \begin{cfa} 5057 struct Y; §\C{// struct Y and struct X are at the same scope}§ 5058 struct X { 5059 struct Y { /* ... */ } y; 5060 }; 5061 \end{cfa} 5062 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. 5063 Note: this is a consequence of the difference in scope rules, which is documented in 3.3. 5064 \item[How widely used:] Seldom. 5065 \end{description} 5066 5067 \item 5068 \begin{description} 5069 \item[Change:] comma expression is disallowed as subscript 5070 \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. 5071 \item[Effect on original feature:] change to semantics of well-defined feature. 5072 \item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]© 5073 \item[How widely used:] seldom. 5074 \end{description} 5075 \end{enumerate} 5045 5076 5046 5077 … … 5080 5111 \leavevmode 5081 5112 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 5082 forall( otype T) T * malloc( void );§\indexc{malloc}§5083 forall( otype T) T * malloc( char fill );5084 forall( otype T) T * malloc( T * ptr, size_t size );5085 forall( otype T) T * malloc( T * ptr, size_t size, unsigned char fill );5086 forall( otype T) T * calloc( size_t nmemb );§\indexc{calloc}§5087 forall( otype T) T * realloc( T * ptr, size_t size );§\indexc{ato}§5088 forall( otype T) T * realloc( T * ptr, size_t size, unsigned char fill );5089 5090 forall( otype T) T * aligned_alloc( size_t alignment );§\indexc{ato}§5091 forall( otype T) T * memalign( size_t alignment ); // deprecated5092 forall( otype T) int posix_memalign( T ** ptr, size_t alignment );5113 forall( dtype T | sized(T) ) T * malloc( void );§\indexc{malloc}§ 5114 forall( dtype T | sized(T) ) T * malloc( char fill ); 5115 forall( dtype T | sized(T) ) T * malloc( T * ptr, size_t size ); 5116 forall( dtype T | sized(T) ) T * malloc( T * ptr, size_t size, unsigned char fill ); 5117 forall( dtype T | sized(T) ) T * calloc( size_t nmemb );§\indexc{calloc}§ 5118 forall( dtype T | sized(T) ) T * realloc( T * ptr, size_t size );§\indexc{ato}§ 5119 forall( dtype T | sized(T) ) T * realloc( T * ptr, size_t size, unsigned char fill ); 5120 5121 forall( dtype T | sized(T) ) T * aligned_alloc( size_t alignment );§\indexc{ato}§ 5122 forall( dtype T | sized(T) ) T * memalign( size_t alignment ); // deprecated 5123 forall( dtype T | sized(T) ) int posix_memalign( T ** ptr, size_t alignment ); 5093 5124 5094 5125 forall( otype T ) T * memset( T * ptr, unsigned char fill ); // use default value '\0' for fill 5095 5126 forall( otype T ) T * memset( T * ptr ); // remove when default value available 5127 5128 forall( dtype T, ttype Params | sized(T) | { void ?{}(T *, Params); } ) T * new( Params p ); 5129 forall( dtype T | { void ^?{}(T *); } ) void delete( T * ptr ); 5130 forall( dtype T, ttype Params | { void ^?{}(T *); void delete(Params); } ) void delete( T * ptr, Params rest ); 5096 5131 \end{cfa} 5097 5132
Note: See TracChangeset
for help on using the changeset viewer.