Context Navigation

-                      r2260ab6c
+                      ra74503ff
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Sun May  6 10:33:53 2018
 %% Update Count     : 3319
+%% Last Modified On : Mon Jul  9 10:49:52 2018
+%% Update Count     : 3361
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 \CFA adds many modern programming-language features that directly lead to increased \emph{\Index{safety}} and \emph{\Index{productivity}}, while maintaining interoperability with existing C programs and achieving similar performance.
 Like C, \CFA is a statically typed, procedural (non-\Index{object-oriented}) language with a low-overhead runtime, meaning there is no global \Index{garbage-collection}, but \Index{regional garbage-collection}\index{garbage-collection!regional} is possible.
 The primary new features include parametric-polymorphic routines and types, exceptions, concurrency, and modules.
+The primary new features include polymorphic routines and types, exceptions, concurrency, and modules.
 One of the main design philosophies of \CFA is to ``\Index{describe not prescribe}'', which means \CFA tries to provide a pathway from low-level C programming to high-level \CFA programming, but it does not force programmers to ``do the right thing''.
 …
 As well, new programs can be written in \CFA using a combination of C and \CFA features.
 \Index*[C++]{\CC{}} had a similar goal 30 years ago, allowing object-oriented programming to be incrementally added to C.
 However, \CC currently has the disadvantages of a strong object-oriented bias, multiple legacy design-choices that cannot be updated, and active divergence of the language model from C, all of which requires significant effort and training to incrementally add \CC to a C-based project.
+\Index*[C++]{\CC{}}~\cite{c++:v1} had a similar goal 30 years ago, allowing object-oriented programming to be incrementally added to C.
+However, \CC currently has the disadvantages of a strong object-oriented bias, multiple legacy design-choices that cannot be updated, and active divergence of the language model from C, requiring significant effort and training to incrementally add \CC to a C-based project.
 In contrast, \CFA has 30 years of hindsight and a clean starting point.
 Like \Index*[C++]{\CC{}}, there may be both an old and new ways to achieve the same effect.
 For example, the following programs compare the \CFA, C, and \CC I/O mechanisms, where the programs output the same result.
 \begin{cquote}
+For example, the following programs compare the C, \CFA, and \CC I/O mechanisms, where the programs output the same result.
+\begin{center}
 \begin{tabular}{@{}l@{\hspace{1.5em}}l@{\hspace{1.5em}}l@{}}
 \multicolumn{1}{c@{\hspace{1.5em}}}{\textbf{C}} & \multicolumn{1}{c}{\textbf{\CFA}}     & \multicolumn{1}{c}{\textbf{\CC}}      \\
 …
 \end{cfa}
 \end{tabular}
 \end{cquote}
+\end{center}
 While the \CFA I/O looks similar to the \Index*[C++]{\CC{}} output style, there are important differences, such as automatic spacing between variables as in \Index*{Python} (see~\VRef{s:IOLibrary}).
 …
 This document is a programmer reference-manual for the \CFA programming language.
 The manual covers the core features of the language and runtime-system, with simple examples illustrating syntax and semantics of each feature.
+The manual covers the core features of the language and runtime-system, with simple examples illustrating syntax and semantics of features.
 The manual does not teach programming, \ie how to combine the new constructs to build complex programs.
 A reader should already have an intermediate knowledge of control flow, data structures, and concurrency issues to understand the ideas presented, as well as some experience programming in C/\CC.
+The reader must have an intermediate knowledge of control flow, data structures, and concurrency issues to understand the ideas presented, as well as some experience programming in C/\CC.
 Implementers should refer to the \CFA Programming Language Specification for details about the language syntax and semantics.
 Changes to the syntax and additional features are expected to be included in later revisions.
 …
 \section{Why fix C?}
 The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from commercial operating-systems (especially UNIX systems) to hobby projects.
+The C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating-systems.
 This installation base and the programmers producing it represent a massive software-engineering investment spanning decades and likely to continue for decades more.
 Even with all its problems, C continues to be popular because it allows writing software at virtually any level in a computer system without restriction.
 For system programming, where direct access to hardware, storage management, and real-time issues are a requirement, C is usually the only language of choice.
 The TIOBE index~\cite{TIOBE} for March 2016 showed the following programming-language popularity: \Index*{Java} 20.5\%, C 14.5\%, \Index*[C++]{\CC{}} 6.7\%, \Csharp 4.3\%, \Index*{Python} 4.3\%, where the next 50 languages are less than 3\% each with a long tail.
 As well, for 30 years, C has been the number 1 and 2 most popular programming language:
+The TIOBE index~\cite{TIOBE} for July 2018 ranks the top 5 most \emph{popular} programming languages as: \Index*{Java} 16\%, C 14\%, \Index*[C++]{\CC{}} 7.5\%, Python 6\%, Visual Basic 4\% = 47.5\%, where the next 50 languages are less than 4\% each, with a long tail.
+The top 3 rankings over the past 30 years are:
 \begin{center}
+\setlength{\tabcolsep}{1.5ex}
+\begin{tabular}{@{}r|c|c|c|c|c|c|c@{}}
+Ranking & 2016  & 2011  & 2006  & 2001  & 1996  & 1991  & 1986          \\
+\hline
+Java    & 1             & 1             & 1             & 3             & 29    & -             & -                     \\
+\hline
+\R{C}   & \R{2} & \R{2} & \R{2} & \R{1} & \R{1} & \R{1} & \R{1}         \\
+\hline
+\CC             & 3             & 3             & 3             & 2             & 2             & 2             & 7                     \\
+\setlength{\tabcolsep}{10pt}
+\begin{tabular}{@{}rccccccc@{}}
+                & 2018  & 2013  & 2008  & 2003  & 1998  & 1993  & 1988  \\ \hline
+Java    & 1             & 2             & 1             & 1             & 16    & -             & -             \\
+\R{C}   & \R{2} & \R{1} & \R{2} & \R{2} & \R{1} & \R{1} & \R{1} \\
+\CC             & 3             & 4             & 3             & 3             & 2             & 2             & 5             \\
 \end{tabular}
 \end{center}
 Hence, C is still an extremely important programming language, with double the usage of \Index*[C++]{\CC{}}; in many cases, \CC is often used solely as a better C.
 Love it or hate it, C has been an important and influential part of computer science for 40 years and its appeal is not diminishing.
 Unfortunately, C has many problems and omissions that make it an unacceptable programming language for modern needs.
+Nevertheless, C has many problems and omissions that make it an unacceptable programming language for modern needs.
 As stated, the goal of the \CFA project is to engineer modern language-features into C in an evolutionary rather than revolutionary way.
 …
 These languages have different syntax and semantics from C, do not interoperate directly with C, and are not systems languages because of restrictive memory-management or garbage collection.
 As a result, there is a significant learning curve to move to these languages, and C legacy-code must be rewritten.
+These costs can be prohibitive for many companies with a large software-base in C/\CC, and a significant number of programmers require retraining to the new programming language.
+The result of this project is a language that is largely backwards compatible with \Index*[C11]{\Celeven{}}~\cite{C11}, but fixes many of the well known C problems while containing modern language-features.
+Without significant extension to the C programming language, it is becoming unable to cope with the needs of modern programming problems and programmers;
+These costs can be prohibitive for many companies with a large software-base in C/\CC, and a significant number of programmers require retraining in the new programming language.
+The result of this project is a language that is largely backwards compatible with \Index*[C11]{\Celeven{}}~\cite{C11}, but fixes many of the well known C problems while adding modern language-features.
+To achieve these goals required a significant engineering exercise, where we had to ``think inside the existing C box''.
+Without these significant extension to C, it is unable to cope with the needs of modern programming problems and programmers;
 as a result, it will fade into disuse.
 Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming language.
 …
 \begin{lstlisting}
 ®forall( otype T )® T identity( T val ) { return val; }
 int forty_two = identity( 42 );                 §\C{// T is bound to int, forty\_two == 42}§
+int forty_two = identity( 42 );                         §\C{// T is bound to int, forty\_two == 42}§
 \end{lstlisting}
 % extending the C type system with parametric polymorphism and overloading, as opposed to the \Index*[C++]{\CC{}} approach of object-oriented extensions.
 …
 \begin{lstlisting}
 forall( dtype T | sized(T) ) T * malloc( void ) { return (T *)malloc( sizeof(T) ); }
 int * ip = malloc();                                    §\C{// select type and size from left-hand side}§
+int * ip = malloc();                                            §\C{// select type and size from left-hand side}§
 double * dp = malloc();
 struct S {...} * sp = malloc();
 …
 Whereas, \CFA wraps each of these routines into ones with the overloaded name ©abs©:
 \begin{cfa}
 char abs( char );
 ®extern "C" {® int abs( int ); ®}®              §\C{// use default C routine for int}§
 long int abs( long int );
 long long int abs( long long int );
 float abs( float );
 double abs( double );
 long double abs( long double );
 float _Complex abs( float _Complex );
 double _Complex abs( double _Complex );
 long double _Complex abs( long double _Complex );
+char ®abs®( char );
+extern "C" { int ®abs®( int ); }                        §\C{// use default C routine for int}§
+long int ®abs®( long int );
+long long int ®abs®( long long int );
+float ®abs®( float );
+double ®abs®( double );
+long double ®abs®( long double );
+float _Complex ®abs®( float _Complex );
+double _Complex ®abs®( double _Complex );
+long double _Complex ®abs®( long double _Complex );
 \end{cfa}
 The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©.
 Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}.
 Then overloading polymorphism uses a mechanism called \newterm{name mangling}\index{mangling!name} to create unique names that are different from C names, which are not mangled.
 Hence, there is the same need as in \CC, to know if a name is a C or \CFA name, so it can be correctly formed.
 There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and type.
+Hence, there is the same need, as in \CC, to know if a name is a C or \CFA name, so it can be correctly formed.
+There is no way around this problem, other than C's approach of creating unique names for each pairing of operation and types.
 This example strongly illustrates a core idea in \CFA: \emph{the \Index{power of a name}}.
 …
 \begin{description}
 \item
 \Indexc{-std=gnu99}\index{compilation option!-std=gnu99@{©-std=gnu99©}}
 The 1999 C standard plus GNU extensions.
+\Indexc{-std=gnu11}\index{compilation option!-std=gnu11@{©-std=gnu11©}}
+The 2011 C standard plus GNU extensions.
 \item
 \Indexc[deletekeywords=inline]{-fgnu89-inline}\index{compilation option!-fgnu89-inline@{\lstinline[deletekeywords=inline]@-fgnu89-inline@}}
 Use the traditional GNU semantics for inline routines in C99 mode, which allows inline routines in header files.
+Use the traditional GNU semantics for inline routines in C11 mode, which allows inline routines in header files.
 \end{description}
 The following new \CFA options are available:
 …
 \begin{cfa}
 #ifndef __CFORALL__
 #include <stdio.h>§\indexc{stdio.h}§    §\C{// C header file}§
+#include <stdio.h>§\indexc{stdio.h}§            §\C{// C header file}§
 #else
 #include <fstream>§\indexc{fstream}§    §\C{// \CFA header file}§
+#include <fstream>§\indexc{fstream}§            §\C{// \CFA header file}§
 #endif
 \end{cfa}
 …
+\section{Backquote Identifiers}
+\label{s:BackquoteIdentifiers}
+\CFA introduces several new keywords (see \VRef{s:CFAKeywords}) that can clash with existing C variable-names in legacy code.
+Keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
+\begin{cfa}
+int ®`®otype®`® = 3;                                            §\C{// make keyword an identifier}§
+double ®`®forall®`® = 3.5;
+\end{cfa}
+Existing C programs with keyword clashes can be converted by enclosing keyword identifiers in backquotes, and eventually the identifier name can be changed to a non-keyword name.
+\VRef[Figure]{f:HeaderFileInterposition} shows how clashes in existing C header-files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©.
+Several common C header-files with keyword clashes are fixed in the standard \CFA header-library, so there is a seamless programming-experience.
+\begin{figure}
+\begin{cfa}
+// include file uses the CFA keyword "with".
+#if ! defined( with )                                           §\C{// nesting ?}§
+#define with ®`®with®`®                                         §\C{// make keyword an identifier}§
+#define __CFA_BFD_H__
+#endif
+®#include_next <bfdlink.h>                                      §\C{// must have internal check for multiple expansion}§
+®
+#if defined( with ) && defined( __CFA_BFD_H__ ) §\C{// reset only if set}§
+#undef with
+#undef __CFA_BFD_H__
+#endif
+\end{cfa}
+\caption{Header-File Interposition}
+\label{f:HeaderFileInterposition}
+\end{figure}
 \section{Constant Underscores}
 Numeric constants are extended to allow \Index{underscore}s\index{constant!underscore}, \eg:
 \begin{cfa}
 ®_®147®_®483®_®648;                                    §\C{// decimal constant}§
 ®_®ul;                                                                §\C{// decimal unsigned long constant}§
 ®_®377;                                                                §\C{// octal constant}§
 x®_®ff®_®ff;                                                   §\C{// hexadecimal constant}§
 x®_®ef3d®_®aa5c;                                               §\C{// hexadecimal constant}§
 .141®_®592®_®654;                                              §\C{// floating constant}§
 ®_®e®_®+1®_®00;                                               §\C{// floating constant}§
 x®_®ff®_®ff®_®p®_®3;                                   §\C{// hexadecimal floating}§
 x®_®1.ffff®_®ffff®_®p®_®128®_®l;               §\C{// hexadecimal floating long constant}§
+®_®147®_®483®_®648;                                            §\C{// decimal constant}§
+®_®ul;                                                                        §\C{// decimal unsigned long constant}§
+®_®377;                                                                        §\C{// octal constant}§
+x®_®ff®_®ff;                                                           §\C{// hexadecimal constant}§
+x®_®ef3d®_®aa5c;                                                       §\C{// hexadecimal constant}§
+.141®_®592®_®654;                                                      §\C{// floating constant}§
+®_®e®_®+1®_®00;                                                       §\C{// floating constant}§
+x®_®ff®_®ff®_®p®_®3;                                           §\C{// hexadecimal floating}§
+x®_®1.ffff®_®ffff®_®p®_®128®_®l;                       §\C{// hexadecimal floating long constant}§
 L®_®§"\texttt{\textbackslash{x}}§®_®§\texttt{ff}§®_®§\texttt{ee}"§;     §\C{// wide character constant}§
 \end{cfa}
 …
-\section{Backquote Identifiers}
-\label{s:BackquoteIdentifiers}
-\CFA introduces several new keywords (see \VRef{s:CFAKeywords}) that can clash with existing C variable-names in legacy code.
-Keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:
-\begin{cfa}
-int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
-double ®`®forall®`® = 3.5;
-\end{cfa}
-Existing C programs with keyword clashes can be converted by enclosing keyword identifiers in backquotes, and eventually the identifier name can be changed to a non-keyword name.
-\VRef[Figure]{f:HeaderFileInterposition} shows how clashes in existing C header-files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©.
-Several common C header-files with keyword clashes are fixed in the standard \CFA header-library, so there is a seamless programming-experience.
-\begin{figure}
-\begin{cfa}
-// include file uses the CFA keyword "with".
-#if ! defined( with )                   §\C{// nesting ?}§
-#define with ®`®with®`®                 §\C{// make keyword an identifier}§
-#define __CFA_BFD_H__
-#endif
-®#include_next <bfdlink.h>              §\C{// must have internal check for multiple expansion}§
-®
-#if defined( with ) && defined( __CFA_BFD_H__ ) §\C{// reset only if set}§
-#undef with
-#undef __CFA_BFD_H__
-#endif
-\end{cfa}
-\caption{Header-File Interposition}
-\label{f:HeaderFileInterposition}
-\end{figure}
 \section{Exponentiation Operator}
 …
 64 -64 0.015625 -0.015625 18.3791736799526 0.264715-1.1922i
 \end{cfa}
 Parenthesis are necessary for the complex constants or the expresion is parsed as ©1.0f+(2.0fi \ 3.0f)+2.0fi©.
+Parenthesis are necessary for the complex constants or the expression is parsed as ©1.0f+(2.0fi \ 3.0f)+2.0fi©.
 The exponentiation operator is available for all the basic types, but for user-defined types, only the integral-computation versions are available.
 For returning an integral value, the user type ©T© must define multiplication, ©*©, and one, ©1©;
 …
+\section{\texorpdfstring{Labelled \protect\lstinline@continue@ / \protect\lstinline@break@}{Labelled continue / break}}
+\section{Control Structures}
+\CFA identifies inconsistent, problematic, and missing control structures in C, and extends, modifies, and adds control structures to increase functionality and safety.
+%\subsection{\texorpdfstring{\protect\lstinline@if@ Statement}{if Statement}}
+\subsection{\texorpdfstring{\LstKeywordStyle{if} Statement}{if Statement}}
+The ©if© expression allows declarations, similar to ©for© declaration expression:
+\begin{cfa}
+if ( int x = f() ) ...                                          §\C{// x != 0}§
+if ( int x = f(), y = g() ) ...                         §\C{// x != 0 \&\& y != 0}§
+if ( int x = f(), y = g(); ®x < y® ) ...        §\C{// relational expression}§
+\end{cfa}
+Unless a relational expression is specified, each variable is compared not equal to 0, which is the standard semantics for the ©if© expression, and the results are combined using the logical ©&&© operator.\footnote{\CC only provides a single declaration always compared not equal to 0.}
+The scope of the declaration(s) is local to the @if@ statement but exist within both the ``then'' and ``else'' clauses.
+%\section{\texorpdfstring{\protect\lstinline@switch@ Statement}{switch Statement}}
+\subsection{\texorpdfstring{\LstKeywordStyle{switch} Statement}{switch Statement}}
+C allows a number of questionable forms for the ©switch© statement:
+\begin{enumerate}
+\item
+By default, the end of a ©case© clause\footnote{
+In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
+\emph{falls through} to the next ©case© clause in the ©switch© statement;
+to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
+\begin{cfa}
+switch ( i ) {
+  case 1:
+        ...
+        // fall-through
+  case 2:
+        ...
+        break;  // exit switch statement
+}
+\end{cfa}
+The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound:
+\begin{cquote}
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\begin{cfa}
+switch ( argc ) {
+  case 3:
+        // open output file
+        // fall-through
+  case 2:
+        // open input file
+        break;  // exit switch statement
+  default:
+        // usage message
+}
+\end{cfa}
+&
+\begin{cfa}
+if ( argc == 3 ) {
+        // open output file
+        ®// open input file
+®} else if ( argc == 2 ) {
+        ®// open input file (duplicate)
+®} else {
+        // usage message
+}
+\end{cfa}
+\end{tabular}
+\end{cquote}
+In this example, case 2 is always done if case 3 is done.
+This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
+C also uses fall-through to handle multiple case-values resulting in the same action:
+\begin{cfa}
+switch ( i ) {
+  ®case 1: case 3: case 5:®     // odd values
+        // odd action
+        break;
+  ®case 2: case 4: case 6:®     // even values
+        // even action
+        break;
+}
+\end{cfa}
+However, this situation is handled in other languages without fall-through by allowing a list of case values.
+While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement.
+Hence, default fall-through semantics results in a large number of programming errors as programmers often \emph{forget} the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
+\item
+It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
+\begin{cfa}
+switch ( i ) {
+  case 0:
+        if ( j < k ) {
+                ...
+          ®case 1:®             // transfer into "if" statement
+                ...
+        } // if
+  case 2:
+        while ( j < 5 ) {
+                ...
+          ®case 3:®             // transfer into "while" statement
+                ...
+        } // while
+} // switch
+\end{cfa}
+The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
+The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
+The technical problem results from the inability to ensure declaration and initialization of variables when blocks are not entered at the beginning.
+There are no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
+Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
+\begin{cfa}
+register int n = (count + 7) / 8;
+switch ( count % 8 ) {
+case 0: do{ *to = *from++;
+case 7:         *to = *from++;
+case 6:         *to = *from++;
+case 5:         *to = *from++;
+case 4:         *to = *from++;
+case 3:         *to = *from++;
+case 2:         *to = *from++;
+case 1:         *to = *from++;
+                } while ( --n > 0 );
+}
+\end{cfa}
+which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
+While efficient, this sort of special purpose usage is questionable:
+\begin{quote}
+Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this
+discovery.~\cite{Duff83}
+\end{quote}
+\item
+It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
+Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
+The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
+hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
+This physical placement can be compared to the physical placement of an ©else© clause at the end of a series of connected ©if©/©else© statements.
+\item
+It is possible to place unreachable code at the start of a ©switch© statement, as in:
+\begin{cfa}
+switch ( x ) {
+        ®int y = 1;®                                                    §\C{// unreachable initialization}§
+        ®x = 7;®                                                                §\C{// unreachable code without label/branch}§
+  case 0: ...
+        ...
+        ®int z = 0;®                                                    §\C{// unreachable initialization, cannot appear after case}§
+        z = 2;
+  case 1:
+        ®x = z;®                                                                §\C{// without fall through, z is uninitialized}§
+}
+\end{cfa}
+While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
+Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
+As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized.
+The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
+\end{enumerate}
+Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
+\begin{itemize}
+\item
+the number of ©switch© statements is small,
+\item
+most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
+\item
+the ©default© clause is usually written as the last case-clause,
+\item
+and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
+\end{itemize}
+These observations put into perspective the \CFA changes to the ©switch©.
+\begin{enumerate}
+\item
+Eliminating default fall-through has the greatest potential for affecting existing code.
+However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, \ie a list of ©case© clauses executing common code, \eg:
+\begin{cfa}
+case 1:  case 2:  case 3: ...
+\end{cfa}
+still works.
+Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
+Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, \eg:
+\begin{cfa}
+®choose® ( i ) {
+  case 1:  case 2:  case 3:
+        ...
+        ®// implicit end of switch (break)
+  ®case 5:
+        ...
+        ®fallthru®;                                                             §\C{// explicit fall through}§
+  case 7:
+        ...
+        ®break®                                                                 §\C{// explicit end of switch (redundant)}§
+  default:
+        j = 3;
+}
+\end{cfa}
+Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
+An implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
+An explicit ©fallthru© is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the ©choose© statement.
+As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers.
+\item
+\Index*{Duff's device} is eliminated from both ©switch© and ©choose© statements, and only invalidates a small amount of very questionable code.
+Hence, the ©case© clause must appear at the same nesting level as the ©switch©/©choose© body, as is done in most other programming languages with ©switch© statements.
+\item
+The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause needs to appear is locations other than at the end.
+Therefore, no change is made for this issue.
+\item
+Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause\footnote{
+Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
+Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
+\begin{cfa}
+switch ( x ) {
+        ®int i = 0;®                                                    §\C{// allowed only at start}§
+  case 0:
+        ...
+        ®int j = 0;®                                                    §\C{// disallowed}§
+  case 1:
+        {
+                ®int k = 0;®                                            §\C{// allowed at different nesting levels}§
+                ...
+          ®case 2:®                                                             §\C{// disallow case in nested statements}§
+        }
+  ...
+}
+\end{cfa}
+\end{enumerate}
+%\section{\texorpdfstring{\protect\lstinline@case@ Clause}{case Clause}}
+\subsection{\texorpdfstring{\LstKeywordStyle{case} Statement}{case Statement}}
+C restricts the ©case© clause of a ©switch© statement to a single value.
+For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
+Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
+Therefore, the ©case© clause is extended with a list of values, as in:
+\begin{cquote}
+\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
+\begin{cfa}
+switch ( i ) {
+  case ®1, 3, 5®:
+        ...
+  case ®2, 4, 6®:
+        ...
+}
+\end{cfa}
+&
+\begin{cfa}
+switch ( i ) {
+  case 1: case 3 : case 5:
+        ...
+  case 2: case 4 : case 6:
+        ...
+}
+\end{cfa}
+&
+\begin{cfa}
+// odd values
+// even values
+\end{cfa}
+\end{tabular}
+\end{cquote}
+In addition, subranges are allowed to specify case values.\footnote{
+gcc has the same mechanism but awkward syntax, \lstinline@2 ...42@, because a space is required after a number, otherwise the period is a decimal point.}
+\begin{cfa}
+switch ( i ) {
+  case ®1~5:®                                   §\C{// 1, 2, 3, 4, 5}§
+        ...
+  case ®10~15:®                                 §\C{// 10, 11, 12, 13, 14, 15}§
+        ...
+}
+\end{cfa}
+Lists of subranges are also allowed.
+\begin{cfa}
+case ®1~5, 12~21, 35~42®:
+\end{cfa}
+%\subsection{\texorpdfstring{Labelled \protect\lstinline@continue@ / \protect\lstinline@break@}{Labelled continue / break}}
+\subsection{\texorpdfstring{Labelled \LstKeywordStyle{continue} / \LstKeywordStyle{break} Statement}{Labelled continue / break Statement}}
 While C provides ©continue© and ©break© statements for altering control flow, both are restricted to one level of nesting for a particular control structure.
 …
 With ©goto©, the label is at the end of the control structure, which fails to convey this important clue early enough to the reader.
 Finally, using an explicit target for the transfer instead of an implicit target allows new constructs to be added or removed without affecting existing constructs.
+The implicit targets of the current ©continue© and ©break©, \ie the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
+\section{\texorpdfstring{\protect\lstinline@switch@ Statement}{switch Statement}}
+C allows a number of questionable forms for the ©switch© statement:
+\begin{enumerate}
+\item
+By default, the end of a ©case© clause\footnote{
+In this section, the term \emph{case clause} refers to either a ©case© or ©default© clause.}
+\emph{falls through} to the next ©case© clause in the ©switch© statement;
+to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©:
+\begin{cfa}
+switch ( i ) {
+  case 1:
+        ...
+        // fall-through
+  case 2:
+        ...
+        break;  // exit switch statement
+}
+\end{cfa}
+The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound:
+\begin{cquote}
+\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
+\begin{cfa}
+switch ( argc ) {
+  case 3:
+        // open output file
+        // fall-through
+  case 2:
+        // open input file
+        break;  // exit switch statement
+  default:
+        // usage message
+}
+\end{cfa}
+&
+\begin{cfa}
+if ( argc == 3 ) {
+        // open output file
+        ®// open input file
+®} else if ( argc == 2 ) {
+        ®// open input file (duplicate)
+®} else {
+        // usage message
+}
+\end{cfa}
+\end{tabular}
+\end{cquote}
+In this example, case 2 is always done if case 3 is done.
+This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine.
+C also uses fall-through to handle multiple case-values resulting in the same action:
+\begin{cfa}
+switch ( i ) {
+  ®case 1: case 3: case 5:®     // odd values
+        // odd action
+        break;
+  ®case 2: case 4: case 6:®     // even values
+        // even action
+        break;
+}
+\end{cfa}
+However, this situation is handled in other languages without fall-through by allowing a list of case values.
+While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement.
+Hence, default fall-through semantics results in a large number of programming errors as programmers often \emph{forget} the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.
+\item
+It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement:
+\begin{cfa}
+switch ( i ) {
+  case 0:
+        if ( j < k ) {
+                ...
+          ®case 1:®             // transfer into "if" statement
+                ...
+        } // if
+  case 2:
+        while ( j < 5 ) {
+                ...
+          ®case 3:®             // transfer into "while" statement
+                ...
+        } // while
+} // switch
+\end{cfa}
+The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties.
+The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it.
+The technical problem results from the inability to ensure declaration and initialization of variables when blocks are not entered at the beginning.
+There are no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it.
+Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}:
+\begin{cfa}
+register int n = (count + 7) / 8;
+switch ( count % 8 ) {
+case 0: do{ *to = *from++;
+case 7:         *to = *from++;
+case 6:         *to = *from++;
+case 5:         *to = *from++;
+case 4:         *to = *from++;
+case 3:         *to = *from++;
+case 2:         *to = *from++;
+case 1:         *to = *from++;
+                } while ( --n > 0 );
+}
+\end{cfa}
+which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N.
+While efficient, this sort of special purpose usage is questionable:
+\begin{quote}
+Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this
+discovery.~\cite{Duff83}
+\end{quote}
+\item
+It is possible to place the ©default© clause anywhere in the list of labelled clauses for a ©switch© statement, rather than only at the end.
+Virtually all programming languages with a ©switch© statement require the ©default© clause to appear last in the case-clause list.
+The logic for this semantics is that after checking all the ©case© clauses without success, the ©default© clause is selected;
+hence, physically placing the ©default© clause at the end of the ©case© clause list matches with this semantics.
+This physical placement can be compared to the physical placement of an ©else© clause at the end of a series of connected ©if©/©else© statements.
+\item
+It is possible to place unreachable code at the start of a ©switch© statement, as in:
+\begin{cfa}
+switch ( x ) {
+        ®int y = 1;®                            §\C{// unreachable initialization}§
+        ®x = 7;®                                        §\C{// unreachable code without label/branch}§
+  case 0: ...
+        ...
+        ®int z = 0;®                            §\C{// unreachable initialization, cannot appear after case}§
+        z = 2;
+  case 1:
+        ®x = z;®                                        §\C{// without fall through, z is uninitialized}§
+}
+\end{cfa}
+While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it.
+Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic.
+As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized.
+The key observation is that the ©switch© statement branches into control structure, \ie there are multiple entry points into its statement body.
+\end{enumerate}
+Before discussing potential language changes to deal with these problems, it is worth observing that in a typical C program:
+\begin{itemize}
+\item
+the number of ©switch© statements is small,
+\item
+most ©switch© statements are well formed (\ie no \Index*{Duff's device}),
+\item
+the ©default© clause is usually written as the last case-clause,
+\item
+and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound.
+\end{itemize}
+These observations put into perspective the \CFA changes to the ©switch©.
+\begin{enumerate}
+\item
+Eliminating default fall-through has the greatest potential for affecting existing code.
+However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, \ie a list of ©case© clauses executing common code, \eg:
+\begin{cfa}
+case 1:  case 2:  case 3: ...
+\end{cfa}
+still works.
+Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments.
+Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, \eg:
+\begin{cfa}
+®choose® ( i ) {
+  case 1:  case 2:  case 3:
+        ...
+        ®// implicit end of switch (break)
+  ®case 5:
+        ...
+        ®fallthru®;                                     §\C{// explicit fall through}§
+  case 7:
+        ...
+        ®break®                                         §\C{// explicit end of switch (redundant)}§
+  default:
+        j = 3;
+}
+\end{cfa}
+Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses;
+An implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause.
+An explicit ©fallthru© is retained because it is a C-idiom most C programmers expect, and its absence might discourage programmers from using the ©choose© statement.
+As well, allowing an explicit ©break© from the ©choose© is a carry over from the ©switch© statement, and expected by C programmers.
+\item
+\Index*{Duff's device} is eliminated from both ©switch© and ©choose© statements, and only invalidates a small amount of very questionable code.
+Hence, the ©case© clause must appear at the same nesting level as the ©switch©/©choose© body, as is done in most other programming languages with ©switch© statements.
+\item
+The issue of ©default© at locations other than at the end of the cause clause can be solved by using good programming style, and there are a few reasonable situations involving fall-through where the ©default© clause needs to appear is locations other than at the end.
+Therefore, no change is made for this issue.
+\item
+Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause\footnote{
+Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.
+Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound.
+\begin{cfa}
+switch ( x ) {
+        ®int i = 0;®                            §\C{// allowed only at start}§
+  case 0:
+        ...
+        ®int j = 0;®                            §\C{// disallowed}§
+  case 1:
+        {
+                ®int k = 0;®                    §\C{// allowed at different nesting levels}§
+                ...
+          ®case 2:®                                     §\C{// disallow case in nested statements}§
+        }
+  ...
+}
+\end{cfa}
+\end{enumerate}
+\section{\texorpdfstring{\protect\lstinline@case@ Clause}{case Clause}}
+C restricts the ©case© clause of a ©switch© statement to a single value.
+For multiple ©case© clauses associated with the same statement, it is necessary to have multiple ©case© clauses rather than multiple values.
+Requiring a ©case© clause for each value does not seem to be in the spirit of brevity normally associated with C.
+Therefore, the ©case© clause is extended with a list of values, as in:
+\begin{cquote}
+\begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}}
+\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\
+\begin{cfa}
+switch ( i ) {
+  case ®1, 3, 5®:
+        ...
+  case ®2, 4, 6®:
+        ...
+}
+\end{cfa}
+&
+\begin{cfa}
+switch ( i ) {
+  case 1: case 3 : case 5:
+        ...
+  case 2: case 4 : case 6:
+        ...
+}
+\end{cfa}
+&
+\begin{cfa}
+// odd values
+// even values
+\end{cfa}
+\end{tabular}
+\end{cquote}
+In addition, subranges are allowed to specify case values.\footnote{
+gcc has the same mechanism but awkward syntax, \lstinline@2 ...42@, because a space is required after a number, otherwise the period is a decimal point.}
+\begin{cfa}
+switch ( i ) {
+  case ®1~5:®                                   §\C{// 1, 2, 3, 4, 5}§
+        ...
+  case ®10~15:®                                 §\C{// 10, 11, 12, 13, 14, 15}§
+        ...
+}
+\end{cfa}
+Lists of subranges are also allowed.
+\begin{cfa}
+case ®1~5, 12~21, 35~42®:
+\end{cfa}
+\section{\texorpdfstring{\protect\lstinline@with@ Statement}{with Statement}}
+Otherwise, the implicit targets of the current ©continue© and ©break©, \ie the closest enclosing loop or ©switch©, change as certain constructs are added or removed.
+%\section{\texorpdfstring{\protect\lstinline@with@ Statement}{with Statement}}
+\section{\texorpdfstring{\LstKeywordStyle{with} Statement}{with Statement}}
 \label{s:WithStatement}
 …
 \begin{cfa}
 void f( S s ) {
         `s.`c; `s.`i; `s.`d;                                    §\C{// access containing fields}§
+        ®s.®c; ®s.®i; ®s.®d;                                    §\C{// access containing fields}§
+}
 \end{cfa}
 …
         double d;
         void f() {                                                              §\C{// implicit ``this'' aggregate}§
                 `this->`c; `this->`i; `this->`d;        §\C{// access containing fields}§
+                ®this->®c; ®this->®i; ®this->®d;        §\C{// access containing fields}§
+        }
+}
 \end{C++}
 Object-oriented nesting of member functions in a \lstinline[language=C++]@class/struct@ allows eliding \lstinline[language=C++]$this->$ because of lexical scoping.
+Object-oriented nesting of member functions in a \lstinline[language=C++]@class/struct@ allows eliding \lstinline[language=C++]@this->@ because of lexical scoping.
 However, for other aggregate parameters, qualification is necessary:
 \begin{cfa}
 …
 int S::f( T & t ) {                                                     §\C{// multiple aggregate parameters}§
         c; i; d;                                                                §\C{\color{red}// this--{\textgreater}.c, this--{\textgreater}.i, this--{\textgreater}.d}§
         `t.`m; `t.`n;                                                   §\C{// must qualify}§
+}
 \end{cfa}
 To simplify the programmer experience, \CFA provides a @with@ statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing the field identifiers.
+        ®t.®m; ®t.®n;                                                   §\C{// must qualify}§
+}
+\end{cfa}
+To simplify the programmer experience, \CFA provides a ©with© statement (see Pascal~\cite[\S~4.F]{Pascal}) to elide aggregate qualification to fields by opening a scope containing the field identifiers.
 Hence, the qualified fields become variables with the side-effect that it is easier to optimizing field references in a block.
 \begin{cfa}
 void f( S & this ) `with ( this )` {            §\C{// with statement}§
+void f( S & this ) ®with ( this )® {            §\C{// with statement}§
         c; i; d;                                                                §\C{\color{red}// this.c, this.i, this.d}§
+}
 …
 with the generality of opening multiple aggregate-parameters:
 \begin{cfa}
 void f( S & s, T & t ) `with ( s, t )` {                §\C{// multiple aggregate parameters}§
+void f( S & s, T & t ) ®with ( s, t )® {        §\C{// multiple aggregate parameters}§
         c; i; d;                                                                §\C{\color{red}// s.c, s.i, s.d}§
         m; n;                                                                   §\C{\color{red}// t.m, t.n}§
 …
 \end{cfa}
 In detail, the @with@ statement has the form:
+In detail, the ©with© statement has the form:
 \begin{cfa}
 §\emph{with-statement}§:
 …
 The difference between parallel and nesting occurs for fields with the same name and type:
 \begin{cfa}
 struct S { int `i`; int j; double m; } s, w;
 struct T { int `i`; int k; int m; } t, w;
+struct S { int ®i®; int j; double m; } s, w;
+struct T { int ®i®; int k; int m; } t, w;
 with ( s, t ) {
         j + k;                                                                  §\C{// unambiguous, s.j + t.k}§
 …
+}
 \end{cfa}
 For parallel semantics, both @s.i@ and @t.i@ are visible, so @i@ is ambiguous without qualification;
 for nested semantics, @t.i@ hides @s.i@, so @i@ implies @t.i@.
+For parallel semantics, both ©s.i© and ©t.i© are visible, so ©i© is ambiguous without qualification;
+for nested semantics, ©t.i© hides ©s.i©, so ©i© implies ©t.i©.
 \CFA's ability to overload variables means fields with the same name but different types are automatically disambiguated, eliminating most qualification when opening multiple aggregates.
 Qualification or a cast is used to disambiguate.
 There is an interesting problem between parameters and the function-body @with@, \eg:
+There is an interesting problem between parameters and the function-body ©with©, \eg:
 \begin{cfa}
 void ?{}( S & s, int i ) with ( s ) {           §\C{// constructor}§
         `s.i = i;`  j = 3;  m = 5.5;                    §\C{// initialize fields}§
+}
 \end{cfa}
 Here, the assignment @s.i = i@ means @s.i = s.i@, which is meaningless, and there is no mechanism to qualify the parameter @i@, making the assignment impossible using the function-body @with@.
+        ®s.i = i;®  j = 3;  m = 5.5;                    §\C{// initialize fields}§
+}
+\end{cfa}
+Here, the assignment ©s.i = i© means ©s.i = s.i©, which is meaningless, and there is no mechanism to qualify the parameter ©i©, making the assignment impossible using the function-body ©with©.
 To solve this problem, parameters are treated like an initialized aggregate:
 \begin{cfa}
 …
 and implicitly opened \emph{after} a function-body open, to give them higher priority:
 \begin{cfa}
 void ?{}( S & s, int `i` ) with ( s ) `with( §\emph{\color{red}params}§ )` {
         s.i = `i`; j = 3; m = 5.5;
+}
 \end{cfa}
 Finally, a cast may be used to disambiguate among overload variables in a @with@ expression:
+void ?{}( S & s, int ®i® ) with ( s ) ®with( §\emph{\color{red}params}§ )® {
+        s.i = ®i®; j = 3; m = 5.5;
+}
+\end{cfa}
+Finally, a cast may be used to disambiguate among overload variables in a ©with© expression:
 \begin{cfa}
 with ( w ) { ... }                                                      §\C{// ambiguous, same name and no context}§
 with ( (S)w ) { ... }                                           §\C{// unambiguous, cast}§
 \end{cfa}
 and @with@ expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate:
+and ©with© expressions may be complex expressions with type reference (see Section~\ref{s:References}) to aggregate:
 % \begin{cfa}
 % struct S { int i, j; } sv;
 …
 class C {
         int i, j;
         int mem() {                                     §\C{\color{red}// implicit "this" parameter}§
                 i = 1;                                  §\C{\color{red}// this->i}§
                 j = 2;                                  §\C{\color{red}// this->j}§
+        int mem() {                                                             §\C{\color{red}// implicit "this" parameter}§
+                i = 1;                                                          §\C{\color{red}// this->i}§
+                j = 2;                                                          §\C{\color{red}// this->j}§
+        }
+}
 …
 \begin{cfa}
 struct S { int i, j; };
 int mem( S & ®this® ) {                 §\C{// explicit "this" parameter}§
         ®this.®i = 1;                           §\C{// "this" is not elided}§
+int mem( S & ®this® ) {                                         §\C{// explicit "this" parameter}§
+        ®this.®i = 1;                                                   §\C{// "this" is not elided}§
         ®this.®j = 2;
+}
 …
 \CFA provides a ©with© clause/statement (see Pascal~\cite[\S~4.F]{Pascal}) to elided the "©this.©" by opening a scope containing field identifiers, changing the qualified fields into variables and giving an opportunity for optimizing qualified references.
 \begin{cfa}
 int mem( S & this ) ®with( this )® { §\C{// with clause}§
         i = 1;                                          §\C{\color{red}// this.i}§
         j = 2;                                          §\C{\color{red}// this.j}§
+int mem( S & this ) ®with( this )® {            §\C{// with clause}§
+        i = 1;                                                                  §\C{\color{red}// this.i}§
+        j = 2;                                                                  §\C{\color{red}// this.j}§
+}
 \end{cfa}
 …
         struct S1 { ... } s1;
         struct S2 { ... } s2;
         ®with( s1 )® {                          §\C{// with statement}§
+        ®with( s1 )® {                                                  §\C{// with statement}§
                 // access fields of s1 without qualification
                 ®with s2® {                             §\C{// nesting}§
+                ®with s2® {                                                     §\C{// nesting}§
                         // access fields of s1 and s2 without qualification
+                }
 …
 Non-local transfer can cause stack unwinding, \ie non-local routine termination, depending on the kind of raise.
 \begin{cfa}
 exception_t E {};                               §\C{// exception type}§
+exception_t E {};                                                       §\C{// exception type}§
 void f(...) {
         ... throw E{}; ...                      §\C{// termination}§
         ... throwResume E{}; ...        §\C{// resumption}§
+        ... throw E{}; ...                                              §\C{// termination}§
+        ... throwResume E{}; ...                                §\C{// resumption}§
+}
 try {
         f(...);
 } catch( E e ; §boolean-predicate§ ) {                  §\C[8cm]{// termination handler}§
+} catch( E e ; §boolean-predicate§ ) {          §\C[8cm]{// termination handler}§
         // recover and continue
 } catchResume( E e ; §boolean-predicate§ ) {    §\C{// resumption handler}\CRT§
+} catchResume( E e ; §boolean-predicate§ ) { §\C{// resumption handler}\CRT§
         // repair and return
 } finally {
 …
 \begin{itemize}
 \item
 if ©R© is an \Index{rvalue} of type ©T &$_1$...&$_r$© where $r \ge 1$ references (©&© symbols) then ©&R© has type ©T ®*®&$_{\color{red}2}$...&$_{\color{red}r}$©, \ie ©T© pointer with $r-1$ references (©&© symbols).
 \item
 if ©L© is an \Index{lvalue} of type ©T &$_1$...&$_l$© where $l \ge 0$ references (©&© symbols) then ©&L© has type ©T ®*®&$_{\color{red}1}$...&$_{\color{red}l}$©, \ie ©T© pointer with $l$ references (©&© symbols).
+if ©R© is an \Index{rvalue} of type ©T &©$_1\cdots$ ©&©$_r$, where $r \ge 1$ references (©&© symbols), than ©&R© has type ©T ®*®&©$_{\color{red}2}\cdots$ ©&©$_{\color{red}r}$, \ie ©T© pointer with $r-1$ references (©&© symbols).
+\item
+if ©L© is an \Index{lvalue} of type ©T &©$_1\cdots$ ©&©$_l$, where $l \ge 0$ references (©&© symbols), than ©&L© has type ©T ®*®&©$_{\color{red}1}\cdots$ ©&©$_{\color{red}l}$, \ie ©T© pointer with $l$ references (©&© symbols).
 \end{itemize}
 The following example shows the first rule applied to different \Index{rvalue} contexts:
 …
 \subsection{Conversion}
+\subsection{String to Value Conversion}
 \leavevmode
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
+void rand48seed( long int s );§\indexc{rand48seed}§
+char rand48();§\indexc{rand48}§
+int rand48();
+unsigned int rand48();
+long int rand48();
+unsigned long int rand48();
+float rand48();
+double rand48();
+float _Complex rand48();
+double _Complex rand48();
+long double _Complex rand48();
+void srandom( unsigned int seed );§\indexc{srandom}§
+char random( void );§\indexc{random}§
+char random( char u );                                          §\C{// [0,u)}§
+char random( char l, char u );                          §\C{// [l,u)}§
+int random( void );
+int random( int u );                                            §\C{// [0,u)}§
+int random( int l, int u );                                     §\C{// [l,u)}§
+unsigned int random( void );
+unsigned int random( unsigned int u );          §\C{// [0,u)}§
+unsigned int random( unsigned int l, unsigned int u ); §\C{// [l,u)}§
+long int random( void );
+long int random( long int u );                          §\C{// [0,u)}§
+long int random( long int l, long int u );      §\C{// [l,u)}§
+unsigned long int random( void );
+unsigned long int random( unsigned long int u ); §\C{// [0,u)}§
+unsigned long int random( unsigned long int l, unsigned long int u ); §\C{// [l,u)}§
+float random( void );                                            §\C{// [0.0, 1.0)}§
+double random( void );                                           §\C{// [0.0, 1.0)}§
+float _Complex random( void );                           §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
+double _Complex random( void );                          §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
+long double _Complex random( void );             §\C{// [0.0, 1.0)+[0.0, 1.0)i}§
 \end{cfa}
 …
 \section{Time}
 \label{s:TimeLib}
+\section{Time Keeping}
+\label{s:TimeKeeping}
 %\subsection{\texorpdfstring{\protect\lstinline@Duration@}{Duration}}
 \subsection{\texorpdfstring{\LstKeywordStyle{\textmd{Duration}}}{Duration}}
+\subsection{\texorpdfstring{\LstBasicStyle{Duration}}{Duration}}
 \label{s:Duration}
 …
 Duration abs( Duration rhs );
-forall( dtype ostype | ostream( ostype ) ) ostype & ?|?( ostype & os, Duration dur );
 Duration ?`ns( int64_t nsec );
 …
 int64_t ?`d( Duration dur );
 int64_t ?`w( Duration dur );
+Duration max( Duration lhs, Duration rhs );
+Duration min( Duration lhs, Duration rhs );
 \end{cfa}
 %\subsection{\texorpdfstring{\protect\lstinline@\timeval@}{timeval}}
 \subsection{\texorpdfstring{\LstKeywordStyle{\textmd{timeval}}}{timeval}}
+\subsection{\texorpdfstring{\LstBasicStyle{timeval}}{timeval}}
 \label{s:timeval}
 …
+\subsection{\texorpdfstring{\protect\lstinline@timespec@}{timespec}}
+%\subsection{\texorpdfstring{\protect\lstinline@timespec@}{timespec}}
+\subsection{\texorpdfstring{\LstBasicStyle{timespec}}{timespec}}
 \label{s:timespec}
 …
+\subsection{\texorpdfstring{\protect\lstinline@itimerval@}{itimerval}}
+%\subsection{\texorpdfstring{\protect\lstinline@itimerval@}{itimerval}}
+\subsection{\texorpdfstring{\LstBasicStyle{itimerval}}{itimerval}}
 \label{s:itimerval}
 …
+\subsection{\texorpdfstring{\protect\lstinline@Time@}{Time}}
+%\subsection{\texorpdfstring{\protect\lstinline@Time@}{Time}}
+\subsection{\texorpdfstring{\LstBasicStyle{Time}}{Time}}
 \label{s:Time}
 …
 void ?{}( Time & time );
 void ?{}( Time & time, zero_t );
+void ?{}( Time & time, int year, int month = 0, int day = 0, int hour = 0, int min = 0, int sec = 0, int nsec = 0 );
 Time ?=?( Time & time, zero_t );
 …
 Time ?=?( Time & time, timespec t );
+Time ?+?( Time & lhs, Duration rhs ) { return (Time)@{ lhs.tv + rhs.tv }; }
+Time ?+?( Duration lhs, Time rhs ) { return rhs + lhs; }
+Time ?+=?( Time & lhs, Duration rhs ) { lhs = lhs + rhs; return lhs; }
+Duration ?-?( Time lhs, Time rhs ) { return (Duration)@{ lhs.tv - rhs.tv }; }
+Time ?-?( Time lhs, Duration rhs ) { return (Time)@{ lhs.tv - rhs.tv }; }
+Time ?-=?( Time & lhs, Duration rhs ) { lhs = lhs - rhs; return lhs; }
+_Bool ?==?( Time lhs, Time rhs ) { return lhs.tv == rhs.tv; }
+_Bool ?!=?( Time lhs, Time rhs ) { return lhs.tv != rhs.tv; }
+_Bool ?<?( Time lhs, Time rhs ) { return lhs.tv < rhs.tv; }
+_Bool ?<=?( Time lhs, Time rhs ) { return lhs.tv <= rhs.tv; }
+_Bool ?>?( Time lhs, Time rhs ) { return lhs.tv > rhs.tv; }
+_Bool ?>=?( Time lhs, Time rhs ) { return lhs.tv >= rhs.tv; }
+forall( dtype ostype | ostream( ostype ) ) ostype & ?|?( ostype & os, Time time );
+Time ?+?( Time & lhs, Duration rhs );
+Time ?+?( Duration lhs, Time rhs );
+Time ?+=?( Time & lhs, Duration rhs );
+Duration ?-?( Time lhs, Time rhs );
+Time ?-?( Time lhs, Duration rhs );
+Time ?-=?( Time & lhs, Duration rhs );
+_Bool ?==?( Time lhs, Time rhs );
+_Bool ?!=?( Time lhs, Time rhs );
+_Bool ?<?( Time lhs, Time rhs );
+_Bool ?<=?( Time lhs, Time rhs );
+_Bool ?>?( Time lhs, Time rhs );
+_Bool ?>=?( Time lhs, Time rhs );
 char * yy_mm_dd( Time time, char * buf );
 …
 size_t strftime( char * buf, size_t size, const char * fmt, Time time );
+forall( dtype ostype | ostream( ostype ) ) ostype & ?|?( ostype & os, Time time );
 \end{cfa}
 …
 %\subsection{\texorpdfstring{\protect\lstinline@Clock@}{Clock}}
 \subsection{\texorpdfstring{\LstKeywordStyle{\textmd{Clock}}}{Clock}}
+\subsection{\texorpdfstring{\LstBasicStyle{Clock}}{Clock}}
 \label{s:Clock}
 …
 void ?{}( Clock & clk );
 void ?{}( Clock & clk, Duration adj );
+Duration getRes();
+Duration getResNsec();                                  §\C{// with nanoseconds}§
+Duration getRes();                                              §\C{// without nanoseconds}§
 Time getTimeNsec();                                             §\C{// with nanoseconds}§
 Time getTime();                                                 §\C{// without nanoseconds}§

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

Context Navigation

Changeset a74503ff

Legend:

doc/user/user.tex

Download in other formats: