Context Navigation

-                      r1ca15c1
+                      rbf1a2bf
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Tue Aug  2 17:39:02 2016
 %% Update Count     : 1286
+%% Last Modified On : Sun Aug 14 08:23:06 2016
+%% Update Count     : 1323
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \item
 \Indexc{-no-include-std}\index{compilation option!-no-include-std@©-no-include-std©}
+\Indexc{-no-include-stdhdr}\index{compilation option!-no-include-stdhdr@©-no-include-stdhdr©}
 Do not supply ©extern "C"© wrappers for \Celeven standard include files (see~\VRef{s:StandardHeaders}).
 \textbf{This option is \emph{not} the default.}
 …
+\section{Backquote Identifiers}
+\label{s:BackquoteIdentifiers}
+\CFA accommodates keyword clashes by syntactic transformations using the \CFA backquote escape-mechanism:
+\begin{lstlisting}
+int `otype` = 3;                                // make keyword an identifier
+double `choose` = 3.5;
+\end{lstlisting}
+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.
+Clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled automatically using the preprocessor, ©#include_next© and ©-I filename©:
+\begin{lstlisting}
+// include file uses the CFA keyword "otype".
+#if ! defined( otype )                  // nesting ?
+#define otype `otype`
+#define __CFA_BFD_H__
+#endif // ! otype
+#include_next <bfd.h>                   // must have internal check for multiple expansion
+#if defined( otype ) && defined( __CFA_BFD_H__ )        // reset only if set
+#undef otype
+#undef __CFA_BFD_H__
+#endif // otype && __CFA_BFD_H__
+\end{lstlisting}
 \section{Type Operators}
 …
 Alternatively, prototype definitions can be eliminated by using a two-pass compilation, and implicitly creating header files for exports.
 The former is easy to do, while the latter is more complex.
+Currently, \CFA does \emph{not} attempt to support named arguments.
+Furthermore, named arguments do not work well in a \CFA-style programming-languages because they potentially introduces a new criteria for type matching.
+For example, it is technically possible to disambiguate between these two overloaded definitions of ©f© based on named arguments at the call site:
+\begin{lstlisting}
+int f( int i, int j );
+int f( int x, double y );
+f( j : 3, i : 4 );                              §\C{// 1st f}§
+f( x : 7, y : 8.1 );                    §\C{// 2nd f}§
+f( 4, 5 );                                              §\C{// ambiguous call}§
+\end{lstlisting}
+However, named arguments compound routine resolution in conjunction with conversions:
+\begin{lstlisting}
+f( i : 3, 5.7 );                                §\C{// ambiguous call ?}§
+\end{lstlisting}
+Depending on the cost associated with named arguments, this call could be resolvable or ambiguous.
+Adding named argument into the routine resolution algorithm does not seem worth the complexity.
+Therefore, \CFA does \emph{not} attempt to support named arguments.
 \item[Default Arguments]
 …
 the allowable positional calls are:
 \begin{lstlisting}
 p();                            §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
 p( 4 );                         §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
 p( 4, 4 );                      §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
 p( 4, 4, 4 );           §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§
+p();                                                    §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
+p( 4 );                                                 §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
+p( 4, 4 );                                              §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
+p( 4, 4, 4 );                                   §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§
 // empty arguments
 p(  , 4, 4 );           §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§
 p( 4,  , 4 );           §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§
 p( 4, 4,   );           §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
 p( 4,  ,   );           §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
 p(  , 4,   );           §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§
 p(  ,  , 4 );           §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§
 p(  ,  ,   );           §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
+p(  , 4, 4 );                                   §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§
+p( 4,  , 4 );                                   §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§
+p( 4, 4,   );                                   §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§
+p( 4,  ,   );                                   §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§
+p(  , 4,   );                                   §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§
+p(  ,  , 4 );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§
+p(  ,  ,   );                                   §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§
 \end{lstlisting}
 Here the missing arguments are inserted from the default values in the parameter list.
 …
 The conflict occurs because both named and ellipse arguments must appear after positional arguments, giving two possibilities:
 \begin{lstlisting}
 p( /* positional */, . . ., /* named */ );
 p( /* positional */, /* named */, . . . );
+p( /* positional */, ... , /* named */ );
+p( /* positional */, /* named */, ... );
 \end{lstlisting}
 While it is possible to implement both approaches, the first possibly is more complex than the second, \eg:
 \begin{lstlisting}
 p( int x, int y, int z, . . . );
 p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, . . ., /* named */ );}§
 p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, . . . );}§
+p( int x, int y, int z, ... );
+p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, ... , /* named */ );}§
+p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§
 \end{lstlisting}
 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.
 …
 The problem is exacerbated with default arguments, \eg:
 \begin{lstlisting}
 void p( int x, int y = 2, int z = 3. . . );
 p( 1, 4, 5, 6, z : 3 );         §\C{// assume p( /* positional */, . . ., /* named */ );}§
 p( 1, z : 3, 4, 5, 6 );         §\C{// assume p( /* positional */, /* named */, . . . );}§
+void p( int x, int y = 2, int z = 3... );
+p( 1, 4, 5, 6, z : 3 );         §\C{// assume p( /* positional */, ... , /* named */ );}§
+p( 1, z : 3, 4, 5, 6 );         §\C{// assume p( /* positional */, /* named */, ... );}§
 \end{lstlisting}
 The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments;
 …
 \subsection{Type Nesting}
 \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.
+\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.
 \begin{figure}
+\centering
 \begin{tabular}{@{}l@{\hspace{3em}}l|l@{}}
 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}}      & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}}      & \multicolumn{1}{|c}{\textbf{\CFA}}    \\
 …
 Mass assignment has the following form:
 \begin{lstlisting}
 [ §\emph{lvalue}§, ..., §\emph{lvalue}§ ] = §\emph{expr}§;
+[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§;
 \end{lstlisting}
 \index{lvalue}
 …
 Multiple assignment has the following form:
 \begin{lstlisting}
 [ §\emph{lvalue}§, . . ., §\emph{lvalue}§ ] = [ §\emph{expr}§, . . ., §\emph{expr}§ ];
+[ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ];
 \end{lstlisting}
 \index{lvalue}
 …
 \begin{lstlisting}
 switch ( i ) {
   ®case 1, 3, 5®:
+  case ®1, 3, 5®:
         ...
   ®case 2, 4, 6®:
+  case ®2, 4, 6®:
         ...
+}
 …
 \begin{lstlisting}
 switch ( i ) {
   ®case 1~5:®
+  case ®1~5:®
         ...
   ®case 10~15:®
+  case ®10~15:®
         ...
+}
 …
 \begin{lstlisting}
 switch ( i )
   case 1 ... 5:
+  case ®1 ... 5®:
         ...
   case 10 ... 15:
+  case ®10 ... 15®:
         ...
+}
 …
+\section{Incompatible}
+The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{ANSI14:C++}.
+\begin{enumerate}
+\item
+\begin{description}
+\item[Change:] add new keywords \\
+New keywords are added to \CFA (see~\VRef{s:NewKeywords}).
+\item[Rationale:] keywords added to implement new semantics of \CFA.
+\item[Effect on original feature:] change to semantics of well-defined feature. \\
+Any ISO C programs using these keywords as identifiers are invalid \CFA programs.
+\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}):
+\item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
+\end{description}
+\item
+\begin{description}
+\item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:
+\begin{lstlisting}
+int rtn( int i );
+int rtn( char c );
+rtn( 'x' );                                             §\C{// programmer expects 2nd rtn to be called}§
+\end{lstlisting}
+\item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
+In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
+\begin{lstlisting}
+sout | 'x' | " " | (int)'x' | endl;
+x 120
+\end{lstlisting}
+Having to cast ©'x'© to ©char© is non-intuitive.
+\item[Effect on original feature:] change to semantics of well-defined feature that depend on:
+\begin{lstlisting}
+sizeof( 'x' ) == sizeof( int )
+\end{lstlisting}
+no long work the same in \CFA programs.
+\item[Difficulty of converting:] simple
+\item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©.
+\end{description}
+\item
+\begin{description}
+\item[Change:] make string literals ©const©:
+\begin{lstlisting}
+char * p = "abc";                               §\C{// valid in C, deprecated in \CFA}§
+char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§
+\end{lstlisting}
+The type of a string literal is changed from ©[] char© to ©const [] char©.
+Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©.
+\item[Rationale:] This change is a safety issue:
+\begin{lstlisting}
+char * p = "abc";
+p[0] = 'w';                                             §\C{// segment fault or change constant literal}§
+\end{lstlisting}
+The same problem occurs when passing a string literal to a routine that changes its argument.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©.
+\item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.
+\end{description}
+\item
+\begin{description}
+\item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
+\begin{lstlisting}
+int i;                                                  §\C{// forward definition}§
+int *j = ®&i®;                                  §\C{// forward reference, valid in C, invalid in \CFA}§
+int i = 0;                                              §\C{// definition}§
+\end{lstlisting}
+is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
+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,
+\begin{lstlisting}
+struct X { int i; struct X *next; };
+static struct X a;                              §\C{// forward definition}§
+static struct X b = { 0, ®&a® };        §\C{// forward reference, valid in C, invalid in \CFA}§
+static struct X a = { 1, &b };  §\C{// definition}§
+\end{lstlisting}
+\item[Rationale:] avoids having different initialization rules for builtin types and userdefined types.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\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.
+\item[How widely used:] seldom
+\end{description}
+\item
+\begin{description}
+\item[Change:] have ©struct© introduce a scope for nested types:
+\begin{lstlisting}
+enum ®Colour® { R, G, B, Y, C, M };
+struct Person {
+        enum ®Colour® { R, G, B };      §\C{// nested type}§
+        struct Face {                           §\C{// nested type}§
+                ®Colour® Eyes, Hair;    §\C{// type defined outside (1 level)}§
+        };
+        ß.ß®Colour® shirt;                      §\C{// type defined outside (top level)}§
+        ®Colour® pants;                         §\C{// type defined same level}§
+        Face looks[10];                         §\C{// type defined same level}§
+};
+®Colour® c = R;                                 §\C{// type/enum defined same level}§
+Personß.ß®Colour® pc = Personß.ßR;      §\C{// type/enum defined inside}§
+Personß.ßFace pretty;                   §\C{// type defined inside}§
+\end{lstlisting}
+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.
+\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
+Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
+\item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] Semantic transformation.
+\item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.
+\end{description}
+\item
+\begin{description}
+\item[Change:] In C++, the name of a nested class is local to its enclosing class.
+\item[Rationale:] C++ classes have member functions which require that classes establish scopes.
+\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:
+\begin{lstlisting}
+struct Y;                                               §\C{// struct Y and struct X are at the same scope}§
+struct X {
+struct Y { /* ... */ } y;
+};
+\end{lstlisting}
+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.
+Note: this is a consequence of the difference in scope rules, which is documented in 3.3.
+\item[How widely used:] Seldom.
+\end{description}
+\item
+\begin{description}
+\item[Change:] comma expression is disallowed as subscript
+\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.
+\item[Effect on original feature:] change to semantics of well-defined feature.
+\item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]©
+\item[How widely used:] seldom.
+\end{description}
+\end{enumerate}
 \section{New Keywords}
 \label{s:NewKeywords}
 \begin{quote2}
+\begin{tabular}{ll}
+©catch©                 & ©lvalue©              \\
+©catchResume©   &                               \\
+©choose©                & ©otype©               \\
+                                &                               \\
+©disable©               & ©throw©               \\
+©dtype©                 & ©throwResume© \\
+                                & ©trait©               \\
+©enable©                & ©try©                 \\
+                                &                               \\
+©fallthrough©                                   \\
+©fallthru©                                              \\
+©finally©                                               \\
+©forall©                                                \\
+©ftype©                                                 \\
+\begin{tabular}{lll}
+©catch©                 & ©fallthrough© & ©otype©               \\
+©catchResume©   & ©fallthru©    & ©throw©               \\
+©choose©                & ©finally©             & ©throwResume© \\
+©disable©               & ©forall©              & ©trait©               \\
+©dtype©                 & ©ftype©               & ©try©                 \\
+©enable©                & ©lvalue©              &                               \\
 \end{tabular}
 \end{quote2}
 …
 \label{s:StandardHeaders}
 C prescribes the following standard header-files:
+C prescribes the following standard header-files~\cite[\S~7.1.2]{C11}:
 \begin{quote2}
 \begin{minipage}{\linewidth}
 …
 \end{minipage}
 \end{quote2}
 For the prescribed head-files, \CFA implicit wraps their includes in an ©extern "C"©;
+For the prescribed head-files, \CFA implicitly wraps their includes in an ©extern "C"©;
 hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
 All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
-\section{Incompatible}
-The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{ANSI14:C++}.
-\begin{enumerate}
-\item
-\begin{description}
-\item[Change:] add new keywords (see~\VRef{s:NewKeywords}) \\
-New keywords are added to \CFA.
-\item[Rationale:] keywords added to implement new semantics of \CFA.
-\item[Effect on original feature:] change to semantics of well-defined feature. \\
-Any ISO C programs using these keywords as identifiers are invalid \CFA programs.
-\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
-\begin{lstlisting}
-int `otype` = 3;                                // make keyword an identifier
-double `choose` = 3.5;
-\end{lstlisting}
-Programs can be converted automatically by enclosing keyword identifiers in backquotes, and the backquotes can be remove later when the identifier name is changed.
-Clashes in C system libraries (include files) can be handled automatically using preprocessor, ©#include_next© and ©-Ifilename©:
-\begin{lstlisting}
-// include file uses the CFA keyword "otype".
-#if ! defined( otype )                  // nesting ?
-#define otype `otype`
-#define __CFA_BFD_H__
-#endif // ! otype
-#include_next <bfd.h>                   // must have internal check for multiple expansion
-#if defined( otype ) && defined( __CFA_BFD_H__ )        // reset only if set
-#undef otype
-#undef __CFA_BFD_H__
-#endif // otype && __CFA_BFD_H__
-\end{lstlisting}
-\item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
-\end{description}
-\item
-\begin{description}
-\item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:
-\begin{lstlisting}
-int rtn( int i );
-int rtn( char c );
-rtn( 'x' );                                             // programmer expects 2nd rtn to be called
-\end{lstlisting}
-\item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.
-In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.
-\begin{lstlisting}
-sout | 'x' | " " | (int)'x' | endl;
-x 120
-\end{lstlisting}
-Having to cast ©'x'© to ©char© is non-intuitive.
-\item[Effect on original feature:] change to semantics of well-defined feature that depend on:
-\begin{lstlisting}
-sizeof( 'x' ) == sizeof( int )
-\end{lstlisting}
-no long work the same in \CFA programs.
-\item[Difficulty of converting:] simple
-\item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©.
-\end{description}
-\item
-\begin{description}
-\item[Change:] make string literals ©const©:
-\begin{lstlisting}
-char * p = "abc";                               // valid in C, deprecated in §\CFA§
-char * q = expr ? "abc" : "de"; // valid in C, invalid in §\CFA§
-\end{lstlisting}
-The type of a string literal is changed from ©[] char© to ©const [] char©.
-Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©.
-\item[Rationale:] This change is a safety issue:
-\begin{lstlisting}
-char * p = "abc";
-p[0] = 'w';                                             // segment fault or change constant literal
-\end{lstlisting}
-The same problem occurs when passing a string literal to a routine that changes its argument.
-\item[Effect on original feature:] change to semantics of well-defined feature.
-\item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©.
-\item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.
-\end{description}
-\item
-\begin{description}
-\item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:
-\begin{lstlisting}
-int i;                                                  // forward definition
-int *j = ®&i®;                                  // forward reference, valid in C, invalid in §\CFA§
-int i = 0;                                              // definition
-\end{lstlisting}
-is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.
-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,
-\begin{lstlisting}
-struct X { int i; struct X *next; };
-static struct X a;                              // forward definition
-static struct X b = { 0, ®&a® };        // forward reference, valid in C, invalid in §\CFA§
-static struct X a = { 1, &b };  // definition
-\end{lstlisting}
-\item[Rationale:] avoids having different initialization rules for builtin types and userdefined types.
-\item[Effect on original feature:] change to semantics of well-defined feature.
-\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.
-\item[How widely used:] seldom
-\end{description}
-\item
-\begin{description}
-\item[Change:] have ©struct© introduce a scope for nested types
-In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing
-Example:
-\begin{lstlisting}
-enum ®Colour® { R, G, B, Y, C, M };
-struct Person {
-        enum ®Colour® { R, G, B };      // nested type
-        struct Face {                           // nested type
-                ®Colour® Eyes, Hair;            // type defined outside (1 level)
-        };
-        ß.ß®Colour® shirt;                              // type defined outside (top level)
-        ®Colour® pants;                         // type defined same level
-        Face looks[10];                         // type defined same level
-};
-®Colour® c = R;                                 // type/enum defined same level
-Personß.ß®Colour® pc = Personß.ßR;      // type/enum defined inside
-Personß.ßFace pretty;                           // type defined inside
-\end{lstlisting}
-\item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism.
-\item[Effect on original feature:] change to semantics of well-defined feature.
-\item[Difficulty of converting:] Semantic transformation.
-\item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.
-\CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.
-Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.
-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.
-\end{description}
-\item
-\begin{description}
-\item[Change:] In C++, the name of a nested class is local to its enclosing class.
-\item[Rationale:] C++ classes have member functions which require that classes establish scopes.
-\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:
-\begin{lstlisting}
-struct Y; // struct Y and struct X are at the same scope
-struct X {
-struct Y { /* ... */ } y;
-};
-\end{lstlisting}
-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.
-Note: this is a consequence of the difference in scope rules, which is documented in 3.3.
-\item[How widely used:] Seldom.
-\end{description}
-\item
-\begin{description}
-\item[Change:] comma expression is disallowed as subscript
-\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.
-\item[Effect on original feature:] change to semantics of well-defined feature.
-\item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]©
-\item[How widely used:] seldom.
-\end{description}
-\end{enumerate}
 …
 \subsection{malloc}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 forall( otype T ) T * malloc( void );§\indexc{malloc}§
 …
 forall( otype T ) T * memset( T * ptr );                                // remove when default value available
 \end{lstlisting}
+\
 \subsection{ato / strto}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 int ato( const char * ptr );§\indexc{ato}§
 …
 long double _Complex strto( const char * sptr, char ** eptr );
 \end{lstlisting}
+\
 \subsection{bsearch / qsort}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 forall( otype T | { int ?<?( T, T ); } )
 …
 void qsort( const T * arr, size_t dimension );§\indexc{qsort}§
 \end{lstlisting}
+\
 \subsection{abs}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 char abs( char );§\indexc{abs}§
 …
 long double abs( long double _Complex );
 \end{lstlisting}
+\
 \subsection{random}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 void rand48seed( long int s );§\indexc{rand48seed}§
 …
 long double _Complex rand48();
 \end{lstlisting}
+\
 \subsection{min / max / clamp / swap}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 forall( otype T | { int ?<?( T, T ); } )
 …
 void swap( T * t1, T * t2 );§\indexc{swap}§
 \end{lstlisting}
+\
 …
 \subsection{General}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 float fabs( float );§\indexc{fabs}§
 …
 long double nan( const char * );
 \end{lstlisting}
+\
 \subsection{Exponential}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 float exp( float );§\indexc{exp}§
 …
 long double logb( long double );
 \end{lstlisting}
+\
 \subsection{Power}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 float sqrt( float );§\indexc{sqrt}§
 …
 long double _Complex pow( long double _Complex, long double _Complex );
 \end{lstlisting}
+\
 \subsection{Trigonometric}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 float sin( float );§\indexc{sin}§
 …
 long double atan( long double, long double );
 \end{lstlisting}
+\
 \subsection{Hyperbolic}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 float sinh( float );§\indexc{sinh}§
 …
 long double _Complex atanh( long double _Complex );
 \end{lstlisting}
+\
 \subsection{Error / Gamma}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 float erf( float );§\indexc{erf}§
 …
 long double tgamma( long double );
 \end{lstlisting}
+\
 \subsection{Nearest Integer}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 float floor( float );§\indexc{floor}§
 …
 long long int llround( long double );
 \end{lstlisting}
+\
 \subsection{Manipulation}
+\leavevmode
 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt]
 float copysign( float, float );§\indexc{copysign}§
 …
 long double scalbln( long double, long int );
 \end{lstlisting}
+\

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset bf1a2bf for doc/user/user.tex

Legend:

doc/user/user.tex

Download in other formats: