Ignore:
File:
1 edited

Legend:

Unmodified
Added
Removed

  • doc/user/user.tex

    r816d61c r421a287  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Fri Jun 16 12:00:01 2017
    14 %% Update Count     : 2433
     13%% Last Modified On : Fri Jun  2 10:07:51 2017
     14%% Update Count     : 2128
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
    … …  
    4343\usepackage[pagewise]{lineno}
    4444\renewcommand{\linenumberfont}{\scriptsize\sffamily}
    45 \input{common}                                          % common CFA document macros
     45\input{common}                                          % bespoke macros used in the document
    4646\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
    4747\usepackage{breakurl}
    … …  
    110110\renewcommand{\subsectionmark}[1]{\markboth{\thesubsection\quad #1}{\thesubsection\quad #1}}
    111111\pagenumbering{roman}
    112 %\linenumbers                                            % comment out to turn off line numbering
     112\linenumbers                                            % comment out to turn off line numbering
    113113
    114114\maketitle
    … …  
    454454the type suffixes ©U©, ©L©, etc. may start with an underscore ©1_U©, ©1_ll© or ©1.0E10_f©.
    455455\end{enumerate}
    456 It is significantly easier to read and enter long constants when they are broken up into smaller groupings (many cultures use comma and/or period among digits for the same purpose).
     456It is significantly easier to read and enter long constants when they are broken up into smaller groupings (most cultures use comma or period among digits for the same purpose).
    457457This extension is backwards compatible, matches with the use of underscore in variable names, and appears in \Index*{Ada} and \Index*{Java} 8.
    458458
    … …  
    464464\begin{cfa}
    465465int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
    466 double ®`®forall®`® = 3.5;
    467 \end{cfa}
    468 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.
     466double ®`®choose®`® = 3.5;
     467\end{cfa}
     468Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to a non-keyword name.
    469469\VRef[Figure]{f:InterpositionHeaderFile} shows how clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©:
    470470
    … …  
    473473// include file uses the CFA keyword "otype".
    474474#if ! defined( otype )                  §\C{// nesting ?}§
    475 #define otype ®`®otype®`®               §\C{// make keyword an identifier}§
     475#define otype `otype`
    476476#define __CFA_BFD_H__
    477477#endif // ! otype
    … …  
    497497\begin{tabular}{@{}ll@{}}
    498498\begin{cfa}
    499 int * x[5]
     499int *x[5]
    500500\end{cfa}
    501501&
    … …  
    508508For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
    509509\begin{cfa}
    510 int ®(*®f®())[®5®]® {...};                              §\C{definition}§
    511  ... ®(*®f®())[®3®]® += 1;                              §\C{usage}§
     510int (*f())[5] {...};                    §\C{}§
     511... (*f())[3] += 1;
    512512\end{cfa}
    513513Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
    … …  
    516516\CFA provides its own type, variable and routine declarations, using a different syntax.
    517517The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
    518 In the following example, \R{red} is the base type and \B{blue} is qualifiers.
     518In the following example, \R{red} is for the base type and \B{blue} is for the qualifiers.
    519519The \CFA declarations move the qualifiers to the left of the base type, \ie move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
    520520\begin{quote2}
    … …  
    534534\end{tabular}
    535535\end{quote2}
    536 The only exception is \Index{bit field} specification, which always appear to the right of the base type.
     536The only exception is bit field specification, which always appear to the right of the base type.
    537537% Specifically, the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array or function return value, and parentheses ©()© are used to indicate a routine parameter.
    538538However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list.
    … …  
    583583\begin{cfa}
    584584int z[ 5 ];
    585 char * w[ 5 ];
    586 double (* v)[ 5 ];
     585char *w[ 5 ];
     586double (*v)[ 5 ];
    587587struct s {
    588588        int f0:3;
    589         int * f1;
    590         int * f2[ 5 ]
     589        int *f1;
     590        int *f2[ 5 ]
    591591};
    592592\end{cfa}
    … …  
    637637\begin{cfa}
    638638int extern x[ 5 ];
    639 const int static * y;
     639const int static *y;
    640640\end{cfa}
    641641&
    … …  
    658658\begin{cfa}
    659659y = (®int *®)x;
    660 i = sizeof(®int * [ 5 ]®);
     660i = sizeof(®int *[ 5 ]®);
    661661\end{cfa}
    662662\end{tabular}
    … …  
    672672C provides a \newterm{pointer type};
    673673\CFA adds a \newterm{reference type}.
    674 These types may be derived from an object or routine type, called the \newterm{referenced type}.
     674These types may be derived from a object or routine type, called the \newterm{referenced type}.
    675675Objects of these types contain an \newterm{address}, which is normally a location in memory, but may also address memory-mapped registers in hardware devices.
    676676An integer constant expression with the value 0, or such an expression cast to type ©void *©, is called a \newterm{null-pointer constant}.\footnote{
    … …  
    729729
    730730A \Index{pointer}/\Index{reference} object is a generalization of an object variable-name, \ie a mutable address that can point to more than one memory location during its lifetime.
    731 (Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime, and like a variable name, may not occupy storage if the literal is embedded directly into instructions.)
     731(Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime, and like a variable name, may not occupy storage as the literal is embedded directly into instructions.)
    732732Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg:
    733733\begin{quote2}
    … …  
    758758\begin{cfa}
    759759p1 = p2;                                                §\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}§
    760 p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *p1 + x}§
     760p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p1 = *p1 + x}§
    761761\end{cfa}
    762762even though the assignment to ©p2© is likely incorrect, and the programmer probably meant:
    … …  
    765765®*®p2 = ®*®p1 + x;                              §\C{// pointed-to value assignment / operation}§
    766766\end{cfa}
    767 The C semantics work well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
     767The C semantics works well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©).
    768768
    769769However, in most other situations, the pointed-to value is requested more often than the pointer address.
    … …  
    799799For a \CFA reference type, the cancellation on the left-hand side of assignment leaves the reference as an address (\Index{lvalue}):
    800800\begin{cfa}
    801 (&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving address in r1 not variable pointed-to by r1}§
     801(&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving address of r1 not variable pointed-to by r1}§
    802802\end{cfa}
    803803Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
    804804\begin{cfa}
    805 (&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in r3}§
     805(&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving address of r3}§
    806806\end{cfa}
    807807Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth.
    … …  
    824824As for a pointer type, a reference type may have qualifiers:
    825825\begin{cfa}
    826 const int cx = 5;                                       §\C{// cannot change cx;}§
    827 const int & cr = cx;                            §\C{// cannot change what cr points to}§
    828 ®&®cr = &cx;                                            §\C{// can change cr}§
    829 cr = 7;                                                         §\C{// error, cannot change cx}§
    830 int & const rc = x;                                     §\C{// must be initialized}§
    831 ®&®rc = &x;                                                     §\C{// error, cannot change rc}§
    832 const int & const crc = cx;                     §\C{// must be initialized}§
    833 crc = 7;                                                        §\C{// error, cannot change cx}§
    834 ®&®crc = &cx;                                           §\C{// error, cannot change crc}§
    835 \end{cfa}
    836 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced\index{coercion} into the reference}:
    837 \begin{cfa}
    838 int & const cr = *0;                            §\C{// where 0 is the int * zero}§
    839 \end{cfa}
    840 Note, constant reference-types do not prevent \Index{addressing errors} because of explicit storage-management:
     826const int cx = 5;                               §\C{// cannot change cx;}§
     827const int & cr = cx;                    §\C{// cannot change what cr points to}§
     828®&®cr = &cx;                                    §\C{// can change cr}§
     829cr = 7;                                                 §\C{// error, cannot change cx}§
     830int & const rc = x;                             §\C{// must be initialized}§
     831®&®rc = &x;                                             §\C{// error, cannot change rc}§
     832const int & const crc = cx;             §\C{// must be initialized}§
     833crc = 7;                                                §\C{// error, cannot change cx}§
     834®&®crc = &cx;                                   §\C{// error, cannot change crc}§
     835\end{cfa}
     836Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be the null pointer unless an arbitrary pointer is coerced into the reference}:
     837\begin{cfa}
     838int & const cr = *0;                    §\C{// where 0 is the int * zero}§
     839\end{cfa}
     840Note, constant reference-types do not prevent addressing errors because of explicit storage-management:
    841841\begin{cfa}
    842842int & const cr = *malloc();
    843843cr = 5;
    844 free( &cr );
    845 cr = 7;                                                         §\C{// unsound pointer dereference}§
    846 \end{cfa}
    847 
    848 The position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
     844delete &cr;
     845cr = 7;                                                 §\C{// unsound pointer dereference}§
     846\end{cfa}
     847
     848Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
    849849The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
    850 \CFA-style declarations (see \VRef{s:Declarations}) attempt to address this issue:
     850\CFA-style declarations attempt to address this issue:
    851851\begin{quote2}
    852852\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
    … …  
    863863\end{tabular}
    864864\end{quote2}
    865 where the \CFA declaration is read left-to-right.
    866 
    867 Finally, like pointers, references are usable and composable with other type operators and generators.
    868 \begin{cfa}
    869 int w, x, y, z, & ar[3] = { x, y, z }; §\C{// initialize array of references}§
    870 &ar[1] = &w;                                            §\C{// change reference array element}§
    871 typeof( ar[1] ) p;                                      §\C{// (gcc) is int, i.e., the type of referenced object}§
    872 typeof( &ar[1] ) q;                                     §\C{// (gcc) is int \&, i.e., the type of reference}§
    873 sizeof( ar[1] ) == sizeof( int );       §\C{// is true, i.e., the size of referenced object}§
    874 sizeof( &ar[1] ) == sizeof( int *)      §\C{// is true, i.e., the size of a reference}§
    875 \end{cfa}
     865where the \CFA declaration is read left-to-right (see \VRef{s:Declarations}).
    876866
    877867In contrast to \CFA reference types, \Index*[C++]{\CC{}}'s reference types are all ©const© references, preventing changes to the reference address, so only value assignment is possible, which eliminates half of the \Index{address duality}.
    878 Also, \CC does not allow \Index{array}s\index{array!reference} of reference\footnote{
    879 The reason for disallowing arrays of reference is unknown, but possibly comes from references being ethereal (like a textual macro), and hence, replaceable by the referant object.}
    880868\Index*{Java}'s reference types to objects (all Java objects are on the heap) are like C pointers, which always manipulate the address, and there is no (bit-wise) object assignment, so objects are explicitly cloned by shallow or deep copying, which eliminates half of the address duality.
    881 
    882 
    883 \subsection{Initialization}
    884869
    885870\Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage of an object.
    … …  
    887872Because the object being initialized has no value, there is only one meaningful semantics with respect to address duality: it must mean address as there is no pointed-to value.
    888873In contrast, the left-hand side of assignment has an address that has a duality.
    889 Therefore, for pointer/reference initialization, the initializing value must be an address not a value.
    890 \begin{cfa}
    891 int * p = &x;                                           §\C{// assign address of x}§
    892 ®int * p = x;®                                          §\C{// assign value of x}§
    893 int & r = x;                                            §\C{// must have address of x}§
    894 \end{cfa}
    895 Like the previous example with C pointer-arithmetic, it is unlikely assigning the value of ©x© into a pointer is meaningful (again, a warning is usually given).
    896 Therefore, for safety, this context requires an address, so it is superfluous to require explicitly taking the address of the initialization object, even though the type is incorrect.
    897 Note, this is strictly a convenience and safety feature for a programmer.
    898 Hence, \CFA allows ©r© to be assigned ©x© because it infers a reference for ©x©, by implicitly inserting a address-of operator, ©&©, and it is an error to put an ©&© because the types no longer match due to the implicit dereference.
    899 Unfortunately, C allows ©p© to be assigned with ©&x© (address) or ©x© (value), but most compilers warn about the latter assignment as being potentially incorrect.
     874Therefore, for pointer/reference initialization, the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}).
     875\begin{cfa}
     876int * p = &x;                           §\C{// must have address of x}§
     877int & r = x;                            §\C{// must have address of x}§
     878\end{cfa}
     879Therefore, it is superfluous to require explicitly taking the address of the initialization object, even though the type is incorrect.
     880Hence, \CFA allows ©r© to be assigned ©x© because it infers a reference for ©x©, by implicitly inserting a address-of operator, ©&©, and it is an error to put an ©&© because the types no longer match.
     881Unfortunately, C allows ©p© to be assigned with ©&x© or ©x©, by value, but most compilers warn about the latter assignment as being potentially incorrect.
     882(\CFA extends pointer initialization so a variable name is automatically referenced, eliminating the unsafe assignment.)
    900883Similarly, when a reference type is used for a parameter/return type, the call-site argument does not require a reference operator for the same reason.
    901884\begin{cfa}
    902 int & f( int & r );                                     §\C{// reference parameter and return}§
    903 z = f( x ) + f( y );                            §\C{// reference operator added, temporaries needed for call results}§
     885int & f( int & r );                             §\C{// reference parameter and return}§
     886z = f( x ) + f( y );                    §\C{// reference operator added, temporaries needed for call results}§
    904887\end{cfa}
    905888Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©r© can be locally reassigned within ©f©.
    … …  
    909892z = temp1 + temp2;
    910893\end{cfa}
    911 This \Index{implicit referencing} is crucial for reducing the syntactic burden for programmers when using references;
     894This implicit referencing is crucial for reducing the syntactic burden for programmers when using references;
    912895otherwise references have the same syntactic  burden as pointers in these contexts.
    913896
    … …  
    916899void f( ®const® int & cr );
    917900void g( ®const® int * cp );
    918 f( 3 );                   g( ®&®3 );
    919 f( x + y );             g( ®&®(x + y) );
     901f( 3 );                   g( &3 );
     902f( x + y );             g( &(x + y) );
    920903\end{cfa}
    921904Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter.
    922 The ©&© before the constant/expression for the pointer-type parameter (©g©) is a \CFA extension necessary to type match and is a common requirement before a variable in C (\eg ©scanf©).
    923 Importantly, ©&3© may not be equal to ©&3©, where the references occur across calls because the temporaries maybe different on each call.
    924 
     905(The ©&© is necessary for the pointer-type parameter to make the types match, and is a common requirement for a C programmer.)
    925906\CFA \emph{extends} this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed-to by the reference parameter and can be changed.\footnote{
    926907If whole program analysis is possible, and shows the parameter is not assigned, \ie it is ©const©, the temporary is unnecessary.}
    … …  
    928909void f( int & r );
    929910void g( int * p );
    930 f( 3 );                   g( ®&®3 );            §\C{// compiler implicit generates temporaries}§
    931 f( x + y );             g( ®&®(x + y) );        §\C{// compiler implicit generates temporaries}§
     911f( 3 );                   g( &3 );              §\C{// compiler implicit generates temporaries}§
     912f( x + y );             g( &(x + y) );  §\C{// compiler implicit generates temporaries}§
    932913\end{cfa}
    933914Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
    … …  
    936917
    937918%\CFA attempts to handle pointers and references in a uniform, symmetric manner.
    938 Finally, C handles \Index{routine object}s in an inconsistent way.
    939 A routine object is both a pointer and a reference (\Index{particle and wave}).
     919However, C handles routine objects in an inconsistent way.
     920A routine object is both a pointer and a reference (particle and wave).
    940921\begin{cfa}
    941922void f( int i );
    942 void (*fp)( int );                                      §\C{// routine pointer}§
    943 fp = f;                                                         §\C{// reference initialization}§
    944 fp = &f;                                                        §\C{// pointer initialization}§
    945 fp = *f;                                                        §\C{// reference initialization}§
    946 fp(3);                                                          §\C{// reference invocation}§
    947 (*fp)(3);                                                       §\C{// pointer invocation}§
    948 \end{cfa}
    949 While C's treatment of routine objects has similarity to inferring a reference type in initialization contexts, the examples are assignment not initialization, and all possible forms of assignment are possible (©f©, ©&f©, ©*f©) without regard for type.
    950 Instead, a routine object should be referenced by a ©const© reference:
    951 \begin{cfa}
    952 ®const® void (®&® fr)( int ) = f;       §\C{// routine reference}§
    953 fr = ...                                                        §\C{// error, cannot change code}§
    954 &fr = ...;                                                      §\C{// changing routine reference}§
    955 fr( 3 );                                                        §\C{// reference call to f}§
    956 (*fr)(3);                                                       §\C{// error, incorrect type}§
     923void (*fp)( int );
     924fp = f;                                                 §\C{// reference initialization}§
     925fp = &f;                                                §\C{// pointer initialization}§
     926fp = *f;                                                §\C{// reference initialization}§
     927fp(3);                                                  §\C{// reference invocation}§
     928(*fp)(3);                                               §\C{// pointer invocation}§
     929\end{cfa}
     930A routine object is best described by a ©const© reference:
     931\begin{cfa}
     932const void (&fr)( int ) = f;
     933fr = ...                                                §\C{// error, cannot change code}§
     934&fr = ...;                                              §\C{// changing routine reference}§
     935fr( 3 );                                                §\C{// reference call to f}§
     936(*fr)(3);                                               §\C{// error, incorrect type}§
    957937\end{cfa}
    958938because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{
    … …  
    960940\CFA allows this additional use of references for routine objects in an attempt to give a more consistent meaning for them.
    961941
    962 
    963 \subsection{Address-of Semantics}
    964 
    965 In C, ©&E© is an rvalue for any expression ©E©.
    966 \CFA extends the ©&© (address-of) operator as follows:
    967 \begin{itemize}
    968 \item
    969 if ©R© is an \Index{rvalue} of type ©T &$_1$...&$_r$© where $r \ge 1$ references (©&© symbols) than ©&R© has type ©T ®*®&$_{\color{red}2}$...&$_{\color{red}r}$©, \ie ©T© pointer with $r-1$ references (©&© symbols).
    970 
    971 \item
    972 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).
    973 \end{itemize}
    974 The following example shows the first rule applied to different \Index{rvalue} contexts:
    975 \begin{cfa}
    976 int x, * px, ** ppx, *** pppx, **** ppppx;
    977 int & rx = x, && rrx = rx, &&& rrrx = rrx ;
    978 x = rrrx;               // rrrx is an lvalue with type int &&& (equivalent to x)
    979 px = &rrrx;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (&x)
    980 ppx = &&rrrx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (&rx)
    981 pppx = &&&rrrx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (&rrx)
    982 ppppx = &&&&rrrx; // starting from &&&rrrx, &&&&rrrx is an rvalue with type int **** (&rrrx)
    983 \end{cfa}
    984 The following example shows the second rule applied to different \Index{lvalue} contexts:
    985 \begin{cfa}
    986 int x, * px, ** ppx, *** pppx;
    987 int & rx = x, && rrx = rx, &&& rrrx = rrx ;
    988 rrrx = 2;               // rrrx is an lvalue with type int &&& (equivalent to x)
    989 &rrrx = px;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (rx)
    990 &&rrrx = ppx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (rrx)
    991 &&&rrrx = pppx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (rrrx)
    992 \end{cfa}
    993 
    994 
    995 \subsection{Conversions}
    996 
    997 C provides a basic implicit conversion to simplify variable usage:
    998 \begin{enumerate}
    999 \setcounter{enumi}{-1}
    1000 \item
    1001 lvalue to rvalue conversion: ©cv T© converts to ©T©, which allows implicit variable dereferencing.
    1002 \begin{cfa}
    1003 int x;
    1004 x + 1;                  // lvalue variable (int) converts to rvalue for expression
    1005 \end{cfa}
    1006 An rvalue has no type qualifiers (©cv©), so the lvalue qualifiers are dropped.
    1007 \end{enumerate}
    1008 \CFA provides three new implicit conversion for reference types to simplify reference usage.
    1009 \begin{enumerate}
    1010 \item
    1011 reference to rvalue conversion: ©cv T &© converts to ©T©, which allows implicit reference dereferencing.
    1012 \begin{cfa}
    1013 int x, &r = x, f( int p );
    1014 x = ®r® + f( ®r® );  // lvalue reference converts to rvalue
    1015 \end{cfa}
    1016 An rvalue has no type qualifiers (©cv©), so the reference qualifiers are dropped.
    1017 
    1018 \item
    1019 lvalue to reference conversion: \lstinline[deletekeywords={lvalue}]@lvalue-type cv1 T@ converts to ©cv2 T &©, which allows implicitly converting variables to references.
    1020 \begin{cfa}
    1021 int x, &r = ®x®, f( int & p ); // lvalue variable (int) convert to reference (int &)
    1022 f( ®x® );               // lvalue variable (int) convert to reference (int &)
    1023 \end{cfa}
    1024 Conversion can restrict a type, where ©cv1© $\le$ ©cv2©, \eg passing an ©int© to a ©const volatile int &©, which has low cost.
    1025 Conversion can expand a type, where ©cv1© $>$ ©cv2©, \eg passing a ©const volatile int© to an ©int &©, which has high cost (\Index{warning});
    1026 furthermore, if ©cv1© has ©const© but not ©cv2©, a temporary variable is created to preserve the immutable lvalue.
    1027 
    1028 \item
    1029 rvalue to reference conversion: ©T© converts to ©cv T &©, which allows binding references to temporaries.
    1030 \begin{cfa}
    1031 int x, & f( int & p );
    1032 f( ®x + 3® );   // rvalue parameter (int) implicitly converts to lvalue temporary reference (int &)
    1033 ®&f®(...) = &x; // rvalue result (int &) implicitly converts to lvalue temporary reference (int &)
    1034 \end{cfa}
    1035 In both case, modifications to the temporary are inaccessible (\Index{warning}).
    1036 Conversion expands the temporary-type with ©cv©, which is low cost since the temporary is inaccessible.
    1037 \end{enumerate}
     942This situation is different from inferring with reference type being used ...
     943
    1038944
    1039945
    1040946\begin{comment}
     947\section{References}
     948
     949By introducing references in parameter types, users are given an easy way to pass a value by reference, without the need for NULL pointer checks.
     950In structures, a reference can replace a pointer to an object that should always have a valid value.
     951When a structure contains a reference, all of its constructors must initialize the reference and all instances of this structure must initialize it upon definition.
     952
     953The syntax for using references in \CFA is the same as \CC with the exception of reference initialization.
     954Use ©&© to specify a reference, and access references just like regular objects, not like pointers (use dot notation to access fields).
     955When initializing a reference, \CFA uses a different syntax which differentiates reference initialization from assignment to a reference.
     956The ©&© is used on both sides of the expression to clarify that the address of the reference is being set to the address of the variable to which it refers.
     957
     958
    1041959From: Richard Bilson <rcbilson@gmail.com>
    1042960Date: Wed, 13 Jul 2016 01:58:58 +0000
    … …  
    12001118\section{Routine Definition}
    12011119
    1202 \CFA also supports a new syntax for routine definition, as well as \Celeven and K\&R routine syntax.
     1120\CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax.
    12031121The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg:
    12041122\begin{cfa}
    … …  
    12201138in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in:
    12211139\begin{cfa}
    1222 [§\,§] g();                                                     §\C{// no input or output parameters}§
    1223 [ void ] g( void );                                     §\C{// no input or output parameters}§
     1140[§\,§] g();                                             §\C{// no input or output parameters}§
     1141[ void ] g( void );                             §\C{// no input or output parameters}§
    12241142\end{cfa}
    12251143
    … …  
    12391157\begin{cfa}
    12401158typedef int foo;
    1241 int f( int (* foo) );                           §\C{// foo is redefined as a parameter name}§
     1159int f( int (* foo) );                   §\C{// foo is redefined as a parameter name}§
    12421160\end{cfa}
    12431161The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo.
    … …  
    12471165C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg:
    12481166\begin{cfa}
    1249 [ int ] f( * int, int * );                      §\C{// returns an integer, accepts 2 pointers to integers}§
    1250 [ * int, int * ] f( int );                      §\C{// returns 2 pointers to integers, accepts an integer}§
     1167[ int ] f( * int, int * );              §\C{// returns an integer, accepts 2 pointers to integers}§
     1168[ * int, int * ] f( int );              §\C{// returns 2 pointers to integers, accepts an integer}§
    12511169\end{cfa}
    12521170The reason for allowing both declaration styles in the new context is for backwards compatibility with existing preprocessor macros that generate C-style declaration-syntax, as in:
    12531171\begin{cfa}
    12541172#define ptoa( n, d ) int (*n)[ d ]
    1255 int f( ptoa( p, 5 ) ) ...                       §\C{// expands to int f( int (*p)[ 5 ] )}§
    1256 [ int ] f( ptoa( p, 5 ) ) ...           §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
     1173int f( ptoa( p, 5 ) ) ...               §\C{// expands to int f( int (*p)[ 5 ] )}§
     1174[ int ] f( ptoa( p, 5 ) ) ...   §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§
    12571175\end{cfa}
    12581176Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms.
    … …  
    12761194        int z;
    12771195        ... x = 0; ... y = z; ...
    1278         ®return;®                                                       §\C{// implicitly return x, y}§
     1196        ®return;® §\C{// implicitly return x, y}§
    12791197}
    12801198\end{cfa}
    … …  
    12861204[ int x, int y ] f() {
    12871205        ...
    1288 }                                                                               §\C{// implicitly return x, y}§
     1206} §\C{// implicitly return x, y}§
    12891207\end{cfa}
    12901208In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered.
    1291 
    1292 Named return values may be used in conjunction with named parameter values;
    1293 specifically, a return and parameter can have the same name.
    1294 \begin{cfa}
    1295 [ int x, int y ] f( int, x, int y ) {
    1296         ...
    1297 }                                                                               §\C{// implicitly return x, y}§
    1298 \end{cfa}
    1299 This notation allows the compiler to eliminate temporary variables in nested routine calls.
    1300 \begin{cfa}
    1301 [ int x, int y ] f( int, x, int y );    §\C{// prototype declaration}§
    1302 int a, b;
    1303 [a, b] = f( f( f( a, b ) ) );
    1304 \end{cfa}
    1305 While the compiler normally ignores parameters names in prototype declarations, here they are used to eliminate temporary return-values by inferring that the results of each call are the inputs of the next call, and ultimately, the left-hand side of the assignment.
    1306 Hence, even without the body of routine ©f© (separate compilation), it is possible to perform a global optimization across routine calls.
    1307 The compiler warns about naming inconsistencies between routine prototype and definition in this case, and behaviour is \Index{undefined} if the programmer is inconsistent.
    13081209
    13091210
    … …  
    13131214as well, parameter names are optional, \eg:
    13141215\begin{cfa}
    1315 [ int x ] f ();                                                 §\C{// returning int with no parameters}§
    1316 [ * int ] g (int y);                                    §\C{// returning pointer to int with int parameter}§
    1317 [ ] h ( int, char );                                    §\C{// returning no result with int and char parameters}§
    1318 [ * int, int ] j ( int );                               §\C{// returning pointer to int and int, with int parameter}§
     1216[ int x ] f ();                                 §\C{// returning int with no parameters}§
     1217[ * int ] g (int y);                    §\C{// returning pointer to int with int parameter}§
     1218[ ] h (int,char);                               §\C{// returning no result with int and char parameters}§
     1219[ * int,int ] j (int);                  §\C{// returning pointer to int and int, with int parameter}§
    13191220\end{cfa}
    13201221This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa).
    … …  
    13241225\multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}}        & \multicolumn{1}{c}{\textbf{C}}        \\
    13251226\begin{cfa}
    1326 [ int ] f( int ), g;
     1227[ int ] f(int), g;
    13271228\end{cfa}
    13281229&
    13291230\begin{cfa}
    1330 int f( int ), g( int );
     1231int f(int), g(int);
    13311232\end{cfa}
    13321233\end{tabular}
    … …  
    13341235Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg:
    13351236\begin{cfa}
    1336 extern [ int ] f ( int );
    1337 static [ int ] g ( int );
     1237extern [ int ] f (int);
     1238static [ int ] g (int);
    13381239\end{cfa}
    13391240
    … …  
    13431244The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg:
    13441245\begin{cfa}
    1345 * [ int x ] () fp;                                              §\C{// pointer to routine returning int with no parameters}§
    1346 * [ * int ] (int y) gp;                                 §\C{// pointer to routine returning pointer to int with int parameter}§
    1347 * [ ] (int,char) hp;                                    §\C{// pointer to routine returning no result with int and char parameters}§
    1348 * [ * int,int ] ( int ) jp;                             §\C{// pointer to routine returning pointer to int and int, with int parameter}§
     1246* [ int x ] () fp;                      §\C{// pointer to routine returning int with no parameters}§
     1247* [ * int ] (int y) gp;         §\C{// pointer to routine returning pointer to int with int parameter}§
     1248* [ ] (int,char) hp;            §\C{// pointer to routine returning no result with int and char parameters}§
     1249* [ * int,int ] (int) jp;       §\C{// pointer to routine returning pointer to int and int, with int parameter}§
    13491250\end{cfa}
    13501251While parameter names are optional, \emph{a routine name cannot be specified};
    13511252for example, the following is incorrect:
    13521253\begin{cfa}
    1353 * [ int x ] f () fp;                                    §\C{// routine name "f" is not allowed}§
     1254* [ int x ] f () fp;            §\C{// routine name "f" is not allowed}§
    13541255\end{cfa}
    13551256
    … …  
    13571258\section{Named and Default Arguments}
    13581259
    1359 Named\index{named arguments}\index{arguments!named} and default\index{default arguments}\index{arguments!default} arguments~\cite{Hardgrave76}\footnote{
     1260Named and default arguments~\cite{Hardgrave76}\footnote{
    13601261Francez~\cite{Francez77} proposed a further extension to the named-parameter passing style, which specifies what type of communication (by value, by reference, by name) the argument is passed to the routine.}
    13611262are two mechanisms to simplify routine call.
    … …  
    15381439        int ;                                   §\C{// disallowed, unnamed field}§
    15391440        int *;                                  §\C{// disallowed, unnamed field}§
    1540         int (*)( int );                 §\C{// disallowed, unnamed field}§
     1441        int (*)(int);                   §\C{// disallowed, unnamed field}§
    15411442};
    15421443\end{cfa}
    … …  
    16611562}
    16621563int main() {
    1663         * [int]( int ) fp = foo();      §\C{// int (*fp)( int )}§
     1564        * [int](int) fp = foo();        §\C{// int (*fp)(int)}§
    16641565        sout | fp( 3 ) | endl;
    16651566}
    … …  
    27822683
    27832684
    2784 \section{Constructors and Destructors}
     2685\subsection{Constructors and Destructors}
    27852686
    27862687\CFA supports C initialization of structures, but it also adds constructors for more advanced initialization.
    … …  
    31133014
    31143015
    3115 \begin{comment}
    31163016\section{Generics}
    31173017
    … …  
    33203220        }
    33213221\end{cfa}
    3322 \end{comment}
    33233222
    33243223
    … …  
    33803279        Complex *p3 = new(0.5, 1.0); // allocate + 2 param constructor
    33813280}
     3281
    33823282\end{cfa}
    33833283
    … …  
    33913291
    33923292
    3393 \begin{comment}
    33943293\subsection{Unsafe C Constructs}
    33953294
    … …  
    34023301The exact set of unsafe C constructs that will be disallowed in \CFA has not yet been decided, but is sure to include pointer arithmetic, pointer casting, etc.
    34033302Once the full set is decided, the rules will be listed here.
    3404 \end{comment}
    34053303
    34063304
    34073305\section{Concurrency}
     3306
     3307Today's processors for nearly all use cases, ranging from embedded systems to large cloud computing servers, are composed of multiple cores, often heterogeneous.
     3308As machines grow in complexity, it becomes more difficult for a program to make the most use of the hardware available.
     3309\CFA includes built-in concurrency features to enable high performance and improve programmer productivity on these multi-/many-core machines.
    34083310
    34093311Concurrency support in \CFA is implemented on top of a highly efficient runtime system of light-weight, M:N, user level threads.
    … …  
    34123314This enables a very familiar interface to all programmers, even those with no parallel programming experience.
    34133315It also allows the compiler to do static type checking of all communication, a very important safety feature.
    3414 This controlled communication with type safety has some similarities with channels in \Index*{Go}, and can actually implement channels exactly, as well as create additional communication patterns that channels cannot.
     3316This controlled communication with type safety has some similarities with channels in \Index*{Go}, and can actually implement
     3317channels exactly, as well as create additional communication patterns that channels cannot.
    34153318Mutex objects, monitors, are used to contain mutual exclusion within an object and synchronization across concurrent threads.
    34163319
    3417 \begin{figure}
    3418 \begin{cfa}
    3419 #include <fstream>
    3420 #include <coroutine>
    3421 
    3422 coroutine Fibonacci {
    3423         int fn;                                                         §\C{// used for communication}§
    3424 };
    3425 void ?{}( Fibonacci * this ) {
    3426         this->fn = 0;
    3427 }
    3428 void main( Fibonacci * this ) {
    3429         int fn1, fn2;                                           §\C{// retained between resumes}§
    3430         this->fn = 0;                                           §\C{// case 0}§
    3431         fn1 = this->fn;
    3432         suspend();                                                      §\C{// return to last resume}§
    3433 
    3434         this->fn = 1;                                           §\C{// case 1}§
    3435         fn2 = fn1;
    3436         fn1 = this->fn;
    3437         suspend();                                                      §\C{// return to last resume}§
    3438 
    3439         for ( ;; ) {                                            §\C{// general case}§
    3440                 this->fn = fn1 + fn2;
    3441                 fn2 = fn1;
    3442                 fn1 = this->fn;
    3443                 suspend();                                              §\C{// return to last resume}§
    3444         } // for
    3445 }
    3446 int next( Fibonacci * this ) {
    3447         resume( this );                                         §\C{// transfer to last suspend}§
    3448         return this->fn;
    3449 }
    3450 int main() {
    3451         Fibonacci f1, f2;
    3452         for ( int i = 1; i <= 10; i += 1 ) {
    3453                 sout | next( &f1 ) | ' ' | next( &f2 ) | endl;
    3454         } // for
    3455 }
    3456 \end{cfa}
    3457 \caption{Fibonacci Coroutine}
    3458 \label{f:FibonacciCoroutine}
    3459 \end{figure}
    3460 
    3461 
    3462 \subsection{Coroutine}
    3463 
    3464 \Index{Coroutines} are the precursor to tasks.
    3465 \VRef[Figure]{f:FibonacciCoroutine} shows a coroutine that computes the \Index*{Fibonacci} numbers.
     3320Three new keywords are added to support these features:
     3321
     3322monitor creates a structure with implicit locking when accessing fields
     3323
     3324mutex implies use of a monitor requiring the implicit locking
     3325
     3326task creates a type with implicit locking, separate stack, and a thread
    34663327
    34673328
    … …  
    34783339\end{cfa}
    34793340
    3480 \begin{figure}
    3481 \begin{cfa}
    3482 #include <fstream>
    3483 #include <kernel>
    3484 #include <monitor>
    3485 #include <thread>
    3486 
    3487 monitor global_t {
    3488         int value;
    3489 };
    3490 
    3491 void ?{}(global_t * this) {
    3492         this->value = 0;
    3493 }
    3494 
    3495 static global_t global;
    3496 
    3497 void increment3( global_t * mutex this ) {
    3498         this->value += 1;
    3499 }
    3500 void increment2( global_t * mutex this ) {
    3501         increment3( this );
    3502 }
    3503 void increment( global_t * mutex this ) {
    3504         increment2( this );
    3505 }
    3506 
    3507 thread MyThread {};
    3508 
    3509 void main( MyThread* this ) {
    3510         for(int i = 0; i < 1_000_000; i++) {
    3511                 increment( &global );
    3512         }
    3513 }
    3514 int main(int argc, char* argv[]) {
    3515         processor p;
    3516         {
    3517                 MyThread f[4];
    3518         }
    3519         sout | global.value | endl;
    3520 }
    3521 \end{cfa}
    3522 \caption{Atomic-Counter Monitor}
    3523 \caption{f:AtomicCounterMonitor}
    3524 \end{figure}
    3525 
    3526 \begin{comment}
    35273341Since a monitor structure includes an implicit locking mechanism, it does not make sense to copy a monitor;
    35283342it is always passed by reference.
    … …  
    35713385}
    35723386\end{cfa}
    3573 \end{comment}
    35743387
    35753388
    … …  
    35793392A task provides mutual exclusion like a monitor, and also has its own execution state and a thread of control.
    35803393Similar to a monitor, a task is defined like a structure:
    3581 
    3582 \begin{figure}
    3583 \begin{cfa}
    3584 #include <fstream>
    3585 #include <kernel>
    3586 #include <stdlib>
    3587 #include <thread>
    3588 
    3589 thread First  { signal_once * lock; };
    3590 thread Second { signal_once * lock; };
    3591 
    3592 void ?{}( First * this, signal_once* lock ) { this->lock = lock; }
    3593 void ?{}( Second * this, signal_once* lock ) { this->lock = lock; }
    3594 
    3595 void main( First * this ) {
    3596         for ( int i = 0; i < 10; i += 1 ) {
    3597                 sout | "First : Suspend No." | i + 1 | endl;
    3598                 yield();
    3599         }
    3600         signal( this->lock );
    3601 }
    3602 
    3603 void main( Second * this ) {
    3604         wait( this->lock );
    3605         for ( int i = 0; i < 10; i += 1 ) {
    3606                 sout | "Second : Suspend No." | i + 1 | endl;
    3607                 yield();
    3608         }
    3609 }
    3610 
    3611 int main( void ) {
    3612         signal_once lock;
    3613         sout | "User main begin" | endl;
    3614         {
    3615                 processor p;
    3616                 {
    3617                         First  f = { &lock };
    3618                         Second s = { &lock };
    3619                 }
    3620         }
    3621         sout | "User main end" | endl;
    3622 }
    3623 \end{cfa}
    3624 \caption{Simple Tasks}
    3625 \label{f:SimpleTasks}
    3626 \end{figure}
    3627 
    3628 
    3629 \begin{comment}
    36303394\begin{cfa}
    36313395type Adder = task {
    … …  
    36813445\end{cfa}
    36823446
     3447
    36833448\subsection{Cooperative Scheduling}
    36843449
    … …  
    37933558}
    37943559\end{cfa}
    3795 \end{comment}
    3796 
     3560
     3561
     3562\section{Modules and Packages }
    37973563
    37983564\begin{comment}
    3799 \section{Modules and Packages }
    3800 
    38013565High-level encapsulation is useful for organizing code into reusable units, and accelerating compilation speed.
    38023566\CFA provides a convenient mechanism for creating, building and sharing groups of functionality that enhances productivity and improves compile time.
    … …  
    44624226
    44634227
    4464 \begin{comment}
    44654228\subsection[Comparing Key Features of CFA]{Comparing Key Features of \CFA}
    44664229
    … …  
    48404603
    48414604
     4605\begin{comment}
    48424606\subsubsection{Modules / Packages}
    48434607
    … …  
    49194683}
    49204684\end{cfa}
     4685\end{comment}
    49214686
    49224687
    … …  
    50794844
    50804845\subsection{Summary of Language Comparison}
    5081 \end{comment}
    5082 
    5083 
    5084 \subsection[C++]{\CC}
     4846
     4847
     4848\subsubsection[C++]{\CC}
    50854849
    50864850\Index*[C++]{\CC{}} is a general-purpose programming language.
    … …  
    51034867
    51044868
    5105 \subsection{Go}
     4869\subsubsection{Go}
    51064870
    51074871\Index*{Go}, also commonly referred to as golang, is a programming language developed at Google in 2007 [.].
    … …  
    51194883
    51204884
    5121 \subsection{Rust}
     4885\subsubsection{Rust}
    51224886
    51234887\Index*{Rust} is a general-purpose, multi-paradigm, compiled programming language developed by Mozilla Research.
    … …  
    51334897
    51344898
    5135 \subsection{D}
     4899\subsubsection{D}
    51364900
    51374901The \Index*{D} programming language is an object-oriented, imperative, multi-paradigm system programming
    … …  
    52455009\item[Rationale:] keywords added to implement new semantics of \CFA.
    52465010\item[Effect on original feature:] change to semantics of well-defined feature. \\
    5247 Any \Celeven programs using these keywords as identifiers are invalid \CFA programs.
     5011Any ISO C programs using these keywords as identifiers are invalid \CFA programs.
    52485012\item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}).
    52495013\item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.
    … …  
    54655229hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
    54665230All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
    5467 For \Index*[C++]{\CC{}}, the name-mangling issue is handled implicitly because most C header-files are augmented with checks for preprocessor variable ©__cplusplus©, which adds appropriate ©extern "C"© qualifiers.
    54685231
    54695232
    … …  
    55485311}
    55495312
    5550 // §\CFA§ safe initialization/copy, i.e., implicit size specification
     5313// §\CFA§ safe initialization/copy
    55515314forall( dtype T | sized(T) ) T * memset( T * dest, char c );§\indexc{memset}§
    55525315forall( dtype T | sized(T) ) T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
    … …  
    56585421\leavevmode
    56595422\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5660 forall( otype T | { int ?<?( T, T ); } ) T min( T t1, T t2 );§\indexc{min}§
    5661 forall( otype T | { int ?>?( T, T ); } ) T max( T t1, T t2 );§\indexc{max}§
    5662 forall( otype T | { T min( T, T ); T max( T, T ); } ) T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
    5663 forall( otype T ) void swap( T * t1, T * t2 );§\indexc{swap}§
     5423forall( otype T | { int ?<?( T, T ); } )
     5424T min( T t1, T t2 );§\indexc{min}§
     5425
     5426forall( otype T | { int ?>?( T, T ); } )
     5427T max( T t1, T t2 );§\indexc{max}§
     5428
     5429forall( otype T | { T min( T, T ); T max( T, T ); } )
     5430T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
     5431
     5432forall( otype T )
     5433void swap( T * t1, T * t2 );§\indexc{swap}§
    56645434\end{cfa}
    56655435
Note: See TracChangeset for help on using the changeset viewer.