Changeset 46e4440e for doc/user


Ignore:
Timestamp:
Jun 13, 2017, 11:53:11 AM (4 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
35dd0f42, 816d61c
Parents:
8d50e34
Message:

third attempt at pointer/reference discussion

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/user/user.tex

    r8d50e34 r46e4440e  
    1111%% Created On       : Wed Apr  6 14:53:29 2016
    1212%% Last Modified By : Peter A. Buhr
    13 %% Last Modified On : Fri Jun  2 10:07:51 2017
    14 %% Update Count     : 2128
     13%% Last Modified On : Tue Jun 13 11:50:27 2017
     14%% Update Count     : 2403
    1515%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    1616
     
    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 (most cultures use comma 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 (many cultures use comma and/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 ®`®choose®`® = 3.5;
    467 \end{cfa}
    468 Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to a non-keyword name.
     466double ®`®forall®`® = 3.5;
     467\end{cfa}
     468Existing 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.
    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`
     475#define otype ®`®otype®`®               §\C{// make keyword an identifier}§
    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{
    511 ... (*f())[3] += 1;
     510int ®(*®f®())[®5®]® {...};                              §\C{definition
     511 ... ®(*®f®())[®3®]® += 1;                              §\C{usage}§
    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 for the base type and \B{blue} is for the qualifiers.
     518In the following example, \R{red} is the base type and \B{blue} is 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 bit field specification, which always appear to the right of the base type.
     536The only exception is \Index{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 a object or routine type, called the \newterm{referenced type}.
     674These types may be derived from an 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 as 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 if 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\ \ *p1 = *p1 + x}§
     760p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *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 works 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 work 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 of r1 not variable pointed-to by r1}§
     801(&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving address in 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 of r2, (\&(\&*)*) cancel giving address of r3}§
     805(&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in 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 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 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\index{coercion} 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 \Index{addressing errors} because of explicit storage-management:
    841841\begin{cfa}
    842842int & const cr = *malloc();
    843843cr = 5;
    844 delete &cr;
    845 cr = 7;                                                 §\C{// unsound pointer dereference}§
    846 \end{cfa}
    847 
    848 Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
     844free( &cr );
     845cr = 7;                                                         §\C{// unsound pointer dereference}§
     846\end{cfa}
     847
     848The 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 attempt to address this issue:
     850\CFA-style declarations (see \VRef{s: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 (see \VRef{s:Declarations}).
     865where the \CFA declaration is read left-to-right.
     866
     867Finally, like pointers, references are usable and composable with other type operators and generators.
     868\begin{cfa}
     869int w, x, y, z, & ar[3] = { x, y, z }; §\C{// initialize array of references}§
     870&ar[1] = &w;                                            §\C{// change reference array element}§
     871typeof( ar[1] ) p;                                      §\C{// (gcc) is int, i.e., the type of referenced object}§
     872typeof( &ar[1] ) q;                                     §\C{// (gcc) is int \&, i.e., the type of reference}§
     873sizeof( ar[1] ) == sizeof( int );       §\C{// is true, i.e., the size of referenced object}§
     874sizeof( &ar[1] ) == sizeof( int *)      §\C{// is true, i.e., the size of a reference}§
     875\end{cfa}
    866876
    867877In 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}.
     878Also, \CC does not allow \Index{array}s\index{array!reference} of reference\footnote{
     879The 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.}
    868880\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{Address-of Semantics}
     884
     885In C, ©&E© is an rvalue for any expression ©E©.
     886\CFA extends the ©&© (address-of) operator as follows:
     887\begin{itemize}
     888\item
     889if ©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).
     890
     891\item
     892if ©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).
     893\end{itemize}
     894The following example shows the first rule applied to different \Index{rvalue} contexts:
     895\begin{cfa}
     896int x, * px, ** ppx, *** pppx, **** ppppx;
     897int & rx = x, && rrx = rx, &&& rrrx = rrx ;
     898x = rrrx;               // rrrx is an lvalue with type int &&& (equivalent to x)
     899px = &rrrx;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (&x)
     900ppx = &&rrrx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (&rx)
     901pppx = &&&rrrx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (&rrx)
     902ppppx = &&&&rrrx; // starting from &&&rrrx, &&&&rrrx is an rvalue with type int **** (&rrrx)
     903\end{cfa}
     904The following example shows the second rule applied to different \Index{lvalue} contexts:
     905\begin{cfa}
     906int x, * px, ** ppx, *** pppx;
     907int & rx = x, && rrx = rx, &&& rrrx = rrx ;
     908rrrx = 2;               // rrrx is an lvalue with type int &&& (equivalent to x)
     909&rrrx = px;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (rx)
     910&&rrrx = ppx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (rrx)
     911&&&rrrx = pppx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (rrrx)
     912\end{cfa}
     913
     914
     915\subsection{Conversions}
     916
     917C provides a basic implicit conversion to simplify variable usage:
     918\begin{enumerate}
     919\setcounter{enumi}{-1}
     920\item
     921lvalue to rvalue conversion: ©cv T© converts to ©T©, which allows implicit variable dereferencing.
     922\begin{cfa}
     923int x;
     924x + 1;                  // lvalue variable (int) converts to rvalue for expression
     925\end{cfa}
     926An rvalue has no type qualifiers (©cv©), so the lvalue qualifiers are dropped.
     927\end{enumerate}
     928\CFA provides three new implicit conversion for reference types to simplify reference usage.
     929\begin{enumerate}
     930\item
     931reference to rvalue conversion: ©cv T &© converts to ©T©, which allows implicit reference dereferencing.
     932\begin{cfa}
     933int x, &r = x, f( int p );
     934x = ®r® + f( ®r® );  // lvalue reference converts to rvalue
     935\end{cfa}
     936An rvalue has no type qualifiers (©cv©), so the reference qualifiers are dropped.
     937
     938\item
     939lvalue to reference conversion: \lstinline[deletekeywords={lvalue}]@lvalue-type cv1 T@ converts to ©cv2 T &©, which allows implicitly converting variables to references.
     940\begin{cfa}
     941int x, &r = ®x®, f( int & p ); // lvalue variable (int) convert to reference (int &)
     942f( ®x® );               // lvalue variable (int) convert to reference (int &)
     943\end{cfa}
     944Conversion can restrict a type, where ©cv1© $\le$ ©cv2©, \eg passing an ©int© to a ©const volatile int &©, which has low cost.
     945Conversion can expand a type, where ©cv1© $>$ ©cv2©, \eg passing a ©const volatile int© to an ©int &©, which has high cost (\Index{warning});
     946furthermore, if ©cv1© has ©const© but not ©cv2©, a temporary variable is created to preserve the immutable lvalue.
     947
     948\item
     949rvalue to reference conversion: ©T© converts to ©cv T &©, which allows binding references to temporaries.
     950\begin{cfa}
     951int x, & f( int & p );
     952f( ®x + 3® );   // rvalue parameter (int) implicitly converts to lvalue temporary reference (int &)
     953®&f®(...) = &x; // rvalue result (int &) implicitly converts to lvalue temporary reference (int &)
     954\end{cfa}
     955In both case, modifications to the temporary are inaccessible (\Index{warning}).
     956Conversion expands the temporary-type with ©cv©, which is low cost since the temporary is inaccessible.
     957\end{enumerate}
     958
     959
     960\subsection{Initialization}
    869961
    870962\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.
     
    872964Because 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.
    873965In contrast, the left-hand side of assignment has an address that has a duality.
    874 Therefore, for pointer/reference initialization, the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}).
    875 \begin{cfa}
    876 int * p = &x;                           §\C{// must have address of x}§
    877 int & r = x;                            §\C{// must have address of x}§
    878 \end{cfa}
    879 Therefore, it is superfluous to require explicitly taking the address of the initialization object, even though the type is incorrect.
    880 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.
    881 Unfortunately, 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.)
     966Therefore, for pointer/reference initialization, the initializing value must be an address not a value.
     967\begin{cfa}
     968int * p = &x;                                           §\C{// assign address of x}§
     969®int * p = x;®                                          §\C{// assign value of x}§
     970int & r = x;                                            §\C{// must have address of x}§
     971\end{cfa}
     972Like 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).
     973Therefore, 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.
     974Note, this is strictly a convenience and safety feature for a programmer.
     975Hence, \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.
     976Unfortunately, C allows ©p© to be assigned with ©&x© (address) or ©x© (value), but most compilers warn about the latter assignment as being potentially incorrect.
    883977Similarly, 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.
    884978\begin{cfa}
    885 int & f( int & r );                             §\C{// reference parameter and return}§
    886 z = f( x ) + f( y );                    §\C{// reference operator added, temporaries needed for call results}§
     979int & f( int & r );                                     §\C{// reference parameter and return}§
     980z = f( x ) + f( y );                            §\C{// reference operator added, temporaries needed for call results}§
    887981\end{cfa}
    888982Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©r© can be locally reassigned within ©f©.
     
    892986z = temp1 + temp2;
    893987\end{cfa}
    894 This implicit referencing is crucial for reducing the syntactic burden for programmers when using references;
     988This \Index{implicit referencing} is crucial for reducing the syntactic burden for programmers when using references;
    895989otherwise references have the same syntactic  burden as pointers in these contexts.
    896990
     
    899993void f( ®const® int & cr );
    900994void g( ®const® int * cp );
    901 f( 3 );                   g( &3 );
    902 f( x + y );             g( &(x + y) );
     995f( 3 );                   g( ®&®3 );
     996f( x + y );             g( ®&®(x + y) );
    903997\end{cfa}
    904998Here, 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.
    905 (The ©&© is necessary for the pointer-type parameter to make the types match, and is a common requirement for a C programmer.)
     999The ©&© 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©).
     1000Importantly, ©&3© may not be equal to ©&3©, where the references occur across calls because the temporaries maybe different on each call.
     1001
    9061002\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{
    9071003If whole program analysis is possible, and shows the parameter is not assigned, \ie it is ©const©, the temporary is unnecessary.}
     
    9091005void f( int & r );
    9101006void g( int * p );
    911 f( 3 );                   g( &3 );              §\C{// compiler implicit generates temporaries}§
    912 f( x + y );             g( &(x + y) );  §\C{// compiler implicit generates temporaries}§
     1007f( 3 );                   g( ®&®3 );            §\C{// compiler implicit generates temporaries}§
     1008f( x + y );             g( ®&®(x + y) );        §\C{// compiler implicit generates temporaries}§
    9131009\end{cfa}
    9141010Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
     
    9171013
    9181014%\CFA attempts to handle pointers and references in a uniform, symmetric manner.
    919 However, C handles routine objects in an inconsistent way.
    920 A routine object is both a pointer and a reference (particle and wave).
     1015Finally, C handles \Index{routine object}s in an inconsistent way.
     1016A routine object is both a pointer and a reference (\Index{particle and wave}).
    9211017\begin{cfa}
    9221018void f( int i );
    923 void (*fp)( int );
    924 fp = f;                                                 §\C{// reference initialization}§
    925 fp = &f;                                                §\C{// pointer initialization}§
    926 fp = *f;                                                §\C{// reference initialization}§
    927 fp(3);                                                  §\C{// reference invocation}§
    928 (*fp)(3);                                               §\C{// pointer invocation}§
    929 \end{cfa}
    930 A routine object is best described by a ©const© reference:
    931 \begin{cfa}
    932 const void (&fr)( int ) = f;
    933 fr = ...                                                §\C{// error, cannot change code}§
    934 &fr = ...;                                              §\C{// changing routine reference}§
    935 fr( 3 );                                                §\C{// reference call to f}§
    936 (*fr)(3);                                               §\C{// error, incorrect type}§
     1019void (*fp)( int );                                      §\C{// routine pointer}§
     1020fp = f;                                                         §\C{// reference initialization}§
     1021fp = &f;                                                        §\C{// pointer initialization}§
     1022fp = *f;                                                        §\C{// reference initialization}§
     1023fp(3);                                                          §\C{// reference invocation}§
     1024(*fp)(3);                                                       §\C{// pointer invocation}§
     1025\end{cfa}
     1026While 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.
     1027Instead, a routine object should be referenced by a ©const© reference:
     1028\begin{cfa}
     1029®const® void (®&® fr)( int ) = f;       §\C{// routine reference}§
     1030fr = ...                                                        §\C{// error, cannot change code}§
     1031&fr = ...;                                                      §\C{// changing routine reference}§
     1032fr( 3 );                                                        §\C{// reference call to f}§
     1033(*fr)(3);                                                       §\C{// error, incorrect type}§
    9371034\end{cfa}
    9381035because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{
    9391036Dynamic code rewriting is possible but only in special circumstances.}
    9401037\CFA allows this additional use of references for routine objects in an attempt to give a more consistent meaning for them.
    941 
    942 This situation is different from inferring with reference type being used ...
    9431038
    9441039
     
    12581353\section{Named and Default Arguments}
    12591354
    1260 Named and default arguments~\cite{Hardgrave76}\footnote{
     1355Named\index{named arguments}\index{arguments!named} and default\index{default arguments}\index{arguments!default} arguments~\cite{Hardgrave76}\footnote{
    12611356Francez~\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.}
    12621357are two mechanisms to simplify routine call.
     
    52295324hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
    52305325All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
     5326For \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.
    52315327
    52325328
     
    53115407}
    53125408
    5313 // §\CFA§ safe initialization/copy
     5409// §\CFA§ safe initialization/copy, i.e., implicit size specification
    53145410forall( dtype T | sized(T) ) T * memset( T * dest, char c );§\indexc{memset}§
    53155411forall( dtype T | sized(T) ) T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
     
    54215517\leavevmode
    54225518\begin{cfa}[aboveskip=0pt,belowskip=0pt]
    5423 forall( otype T | { int ?<?( T, T ); } )
    5424 T min( T t1, T t2 );§\indexc{min}§
    5425 
    5426 forall( otype T | { int ?>?( T, T ); } )
    5427 T max( T t1, T t2 );§\indexc{max}§
    5428 
    5429 forall( otype T | { T min( T, T ); T max( T, T ); } )
    5430 T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
    5431 
    5432 forall( otype T )
    5433 void swap( T * t1, T * t2 );§\indexc{swap}§
     5519forall( otype T | { int ?<?( T, T ); } ) T min( T t1, T t2 );§\indexc{min}§
     5520forall( otype T | { int ?>?( T, T ); } ) T max( T t1, T t2 );§\indexc{max}§
     5521forall( otype T | { T min( T, T ); T max( T, T ); } ) T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
     5522forall( otype T ) void swap( T * t1, T * t2 );§\indexc{swap}§
    54345523\end{cfa}
    54355524
Note: See TracChangeset for help on using the changeset viewer.