Changeset 917ab04 for doc/user/user.tex


Ignore:
Timestamp:
May 21, 2017, 11:24:35 PM (7 years ago)
Author:
Peter A. Buhr <pabuhr@…>
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
Message:

rewrite section syntax ambiguites

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/user/user.tex

    r88e0080 r917ab04  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Fri May 19 11:54:31 2017
    14 %% Update Count     : 1735
     13%% Last Modified On : Sun May 21 23:16:45 2017
     14%% Update Count     : 1817
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    9494\author{
    9595\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 \\
    9797\Large Glen Ditchfield, Rodolfo G. Esteves, Aaron Moss, Rob Schluntz
    9898}% author
     
    644644\end{quote2}
    645645
    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}
     646The 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}
     651y = (®* int®)x;
     652i = sizeof(®[ 5 ] * int®);
     653\end{cfa}
     654&
     655\begin{cfa}
     656y = (®int *®)x;
     657i = sizeof(®int *[ 5 ]®);
     658\end{cfa}
     659\end{tabular}
     660\end{quote2}
    655661
    656662Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration.
     
    11051111> already.
    11061112\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}
    11261113
    11271114
     
    48424829
    48434830
    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
     4833C has a number of syntax ambiguities, which are resolved by taking the longest sequence of overlapping characters that constitute a token.
     4834For example, the program fragment ©x+++++y© is parsed as \lstinline[showspaces=true]@x ++ ++ + y@ because operator tokens ©++© and ©+© overlap.
     4835Unfortunately, the longest sequence violates a constraint on increment operators, even though the parse \lstinline[showspaces=true]@x ++ + ++ y@ might yield a correct expression.
     4836Hence, C programmers are aware that spaces have to added to disambiguate certain syntactic cases.
     4837
     4838In \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}
     4843By default, the first interpretation is selected, which does not yield a meaningful string in the language.
     4844Therefore, \CFA does a lexical look-ahead for the second case, and backtracks to return the leading unary operator and reparses the trailing operator identifier.
     4845Otherwise a space is needed between the unary operator and operator identifier to disambiguate this common case.
     4846
     4847A similar issue occurs with the dereference, ©*?(...)©, and routine-call, ©?()(...)© identifiers.
     4848The ambiguity occurs when the deference operator has no parameters:
     4849\begin{cfa}
     4850*?()§\color{red}\textvisiblespace...§ ;
     4851*?()§\color{red}\textvisiblespace...§(...) ;
     4852\end{cfa}
     4853requiring arbitrary whitespace look-ahead for the routine-call parameter list to disambiguate.
     4854However, the dereference operator \emph{must} have a parameter/argument to dereference ©*?(...)©.
     4855Hence, always interpreting the string ©*?()© as \lstinline[showspaces=true]@* ?()@ does not preclude any meaningful program.
     4856
     4857The remaining cases are with the increment/decrement operators and conditional expression, \eg:
     4858\begin{cfa}
     4859i++?§\color{red}\textvisiblespace...§(...);
     4860i?++§\color{red}\textvisiblespace...§(...);
     4861\end{cfa}
     4862requiring arbitrary whitespace look-ahead for the routine-call parameter list, even though that interpretation is an incorrect expression (juxtaposed identifiers).
     4863Therefore, it is necessary to disambiguate these cases with a space:
     4864\begin{cfa}
     4865i++§\color{red}\textvisiblespace§? i : 0;
     4866i?§\color{red}\textvisiblespace§++i : 0;
     4867\end{cfa}
    50044868
    50054869
     
    50084872
    50094873\begin{quote2}
    5010 \begin{tabular}{lll}
     4874\begin{tabular}{llll}
    50114875\begin{tabular}{@{}l@{}}
    50124876©_AT©                   \\
     
    50164880©coroutine©             \\
    50174881©disable©               \\
    5018 ©dtype©                 \\
    5019 ©enable©                \\
    50204882\end{tabular}
    50214883&
    50224884\begin{tabular}{@{}l@{}}
     4885©dtype©                 \\
     4886©enable©                \\
    50234887©fallthrough©   \\
    50244888©fallthru©              \\
    50254889©finally©               \\
    50264890©forall©                \\
     4891\end{tabular}
     4892&
     4893\begin{tabular}{@{}l@{}}
    50274894©ftype©                 \\
    50284895©lvalue©                \\
    50294896©monitor©               \\
    50304897©mutex©                 \\
     4898©one_t©                 \\
     4899©otype©                 \\
    50314900\end{tabular}
    50324901&
    50334902\begin{tabular}{@{}l@{}}
    5034 ©one_t©                 \\
    5035 ©otype©                 \\
    50364903©throw©                 \\
    50374904©throwResume©   \\
     
    50434910\end{tabular}
    50444911\end{quote2}
     4912
     4913
     4914\section{Incompatible}
     4915
     4916The 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 \\
     4923New 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. \\
     4926Any 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 \\
     4934K\&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}
     4937x;                                                              §\C{// int x}§
     4938*y;                                                             §\C{// int *y}§
     4939f( p1, p2 );                                    §\C{// int f( int p1, int p2 );}§
     4940g( 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}
     4944f( 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{
     4951At 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. \\
     4953Any 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}
     4962int rtn( int i );
     4963int rtn( char c );
     4964rtn( '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.
     4967In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
     4968\begin{cfa}
     4969sout | 'x' | " " | (int)'x' | endl;
     4970x 120
     4971\end{cfa}
     4972Having 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}
     4975sizeof( 'x' ) == sizeof( int )
     4976\end{cfa}
     4977no 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}
     4986char * p = "abc";                               §\C{// valid in C, deprecated in \CFA}§
     4987char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
     4988\end{cfa}
     4989The type of a string literal is changed from ©[] char© to ©const [] char©.
     4990Similarly, 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}
     4993char * p = "abc";
     4994p[0] = 'w';                                             §\C{// segment fault or change constant literal}§
     4995\end{cfa}
     4996The 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}
     5006int i;                                                  §\C{// forward definition}§
     5007int *j = ®&i®;                                  §\C{// forward reference, valid in C, invalid in \CFA}§
     5008int i = 0;                                              §\C{// definition}§
     5009\end{cfa}
     5010is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
     5011This 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}
     5013struct X { int i; struct X *next; };
     5014static struct X a;                              §\C{// forward definition}§
     5015static struct X b = { 0, ®&a® };        §\C{// forward reference, valid in C, invalid in \CFA}§
     5016static 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}
     5028enum ®Colour® { R, G, B, Y, C, M };
     5029struct 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}§
     5039Person®.Colour® pc = Person®.®R;        §\C{// type/enum defined inside}§
     5040Person®.®Face pretty;                   §\C{// type defined inside}§
     5041\end{cfa}
     5042In 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}.
     5044Nested 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}
     5057struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
     5058struct X {
     5059struct Y { /* ... */ } y;
     5060};
     5061\end{cfa}
     5062All 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.
     5063Note: 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}
    50455076
    50465077
     
    50805111\leavevmode
    50815112\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 );             // deprecated
    5092 forall( otype T ) int posix_memalign( T ** ptr, size_t alignment );
     5113forall( dtype T | sized(T) ) T * malloc( void );§\indexc{malloc}§
     5114forall( dtype T | sized(T) ) T * malloc( char fill );
     5115forall( dtype T | sized(T) ) T * malloc( T * ptr, size_t size );
     5116forall( dtype T | sized(T) ) T * malloc( T * ptr, size_t size, unsigned char fill );
     5117forall( dtype T | sized(T) ) T * calloc( size_t nmemb );§\indexc{calloc}§
     5118forall( dtype T | sized(T) ) T * realloc( T * ptr, size_t size );§\indexc{ato}§
     5119forall( dtype T | sized(T) ) T * realloc( T * ptr, size_t size, unsigned char fill );
     5120
     5121forall( dtype T | sized(T) ) T * aligned_alloc( size_t alignment );§\indexc{ato}§
     5122forall( dtype T | sized(T) ) T * memalign( size_t alignment );          // deprecated
     5123forall( dtype T | sized(T) ) int posix_memalign( T ** ptr, size_t alignment );
    50935124
    50945125forall( otype T ) T * memset( T * ptr, unsigned char fill ); // use default value '\0' for fill
    50955126forall( otype T ) T * memset( T * ptr );                                // remove when default value available
     5127
     5128forall( dtype T, ttype Params | sized(T) | { void ?{}(T *, Params); } ) T * new( Params p );
     5129forall( dtype T | { void ^?{}(T *); } ) void delete( T * ptr );
     5130forall( dtype T, ttype Params | { void ^?{}(T *); void delete(Params); } ) void delete( T * ptr, Params rest );
    50965131\end{cfa}
    50975132
Note: See TracChangeset for help on using the changeset viewer.