Context Navigation

-                      r8d50e34
+                      r46e4440e
 %% Created On       : Wed Apr  6 14:53:29 2016
 %% Last Modified By : Peter A. Buhr
 %% Last Modified On : Fri Jun  2 10:07:51 2017
 %% Update Count     : 2128
+%% Last Modified On : Tue Jun 13 11:50:27 2017
+%% Update Count     : 2403
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 the type suffixes ©U©, ©L©, etc. may start with an underscore ©1_U©, ©1_ll© or ©1.0E10_f©.
 \end{enumerate}
 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).
+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).
 This extension is backwards compatible, matches with the use of underscore in variable names, and appears in \Index*{Ada} and \Index*{Java} 8.
 …
 \begin{cfa}
 int ®`®otype®`® = 3;                    §\C{// make keyword an identifier}§
 double ®`®choose®`® = 3.5;
 \end{cfa}
 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.
+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:InterpositionHeaderFile} shows how clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled using preprocessor \newterm{interposition}: ©#include_next© and ©-I filename©:
 …
 // include file uses the CFA keyword "otype".
 #if ! defined( otype )                  §\C{// nesting ?}§
 #define otype `otype`
+#define otype ®`®otype®`®               §\C{// make keyword an identifier}§
 #define __CFA_BFD_H__
 #endif // ! otype
 …
 \begin{tabular}{@{}ll@{}}
 \begin{cfa}
 int *x[5]
+int * x[5]
 \end{cfa}
+&
 …
 For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
 \begin{cfa}
 int (*f())[5] {...};                    §\C{}§
+... (*f())[3] += 1;
+int ®(*®f®())[®5®]® {...};                              §\C{definition}§
+ ... ®(*®f®())[®3®]® += 1;                              §\C{usage}§
 \end{cfa}
 Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
 …
 \CFA provides its own type, variable and routine declarations, using a different syntax.
 The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
 In the following example, \R{red} is for the base type and \B{blue} is for the qualifiers.
+In the following example, \R{red} is the base type and \B{blue} is qualifiers.
 The \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.
 \begin{quote2}
 …
 \end{tabular}
 \end{quote2}
 The only exception is bit field specification, which always appear to the right of the base type.
+The only exception is \Index{bit field} specification, which always appear to the right of the base type.
 % 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.
 However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list.
 …
 \begin{cfa}
 int z[ 5 ];
 char *w[ 5 ];
 double (*v)[ 5 ];
+char * w[ 5 ];
+double (* v)[ 5 ];
 struct s {
         int f0:3;
         int *f1;
         int *f2[ 5 ]
+        int * f1;
+        int * f2[ 5 ]
 };
 \end{cfa}
 …
 \begin{cfa}
 int extern x[ 5 ];
 const int static *y;
+const int static * y;
 \end{cfa}
+&
 …
 \begin{cfa}
 y = (®int *®)x;
 i = sizeof(®int *[ 5 ]®);
+i = sizeof(®int * [ 5 ]®);
 \end{cfa}
 \end{tabular}
 …
 C provides a \newterm{pointer type};
 \CFA adds a \newterm{reference type}.
 These types may be derived from a object or routine type, called the \newterm{referenced type}.
+These types may be derived from an object or routine type, called the \newterm{referenced type}.
 Objects of these types contain an \newterm{address}, which is normally a location in memory, but may also address memory-mapped registers in hardware devices.
 An integer constant expression with the value 0, or such an expression cast to type ©void *©, is called a \newterm{null-pointer constant}.\footnote{
 …
 A \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.
 (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.)
+(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.)
 Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg:
 \begin{quote2}
 …
 \begin{cfa}
 p1 = p2;                                                §\C{// p1 = p2\ \ rather than\ \ *p1 = *p2}§
 p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p1 = *p1 + x}§
+p2 = p1 + x;                                    §\C{// p2 = p1 + x\ \ rather than\ \ *p2 = *p1 + x}§
 \end{cfa}
 even though the assignment to ©p2© is likely incorrect, and the programmer probably meant:
 …
 ®*®p2 = ®*®p1 + x;                              §\C{// pointed-to value assignment / operation}§
 \end{cfa}
 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©).
+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©).
 However, in most other situations, the pointed-to value is requested more often than the pointer address.
 …
 For a \CFA reference type, the cancellation on the left-hand side of assignment leaves the reference as an address (\Index{lvalue}):
 \begin{cfa}
 (&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving address of r1 not variable pointed-to by r1}§
+(&®*®)r1 = &x;                                  §\C{// (\&*) cancel giving address in r1 not variable pointed-to by r1}§
 \end{cfa}
 Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}):
 \begin{cfa}
 (&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving address of r3}§
+(&(&®*®)®*®)r3 = &(&®*®)r2;             §\C{// (\&*) cancel giving address in r2, (\&(\&*)*) cancel giving address in r3}§
 \end{cfa}
 Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth.
 …
 As for a pointer type, a reference type may have qualifiers:
 \begin{cfa}
 const int cx = 5;                               §\C{// cannot change cx;}§
 const int & cr = cx;                    §\C{// cannot change what cr points to}§
 ®&®cr = &cx;                                    §\C{// can change cr}§
 cr = 7;                                                 §\C{// error, cannot change cx}§
 int & const rc = x;                             §\C{// must be initialized}§
 ®&®rc = &x;                                             §\C{// error, cannot change rc}§
 const int & const crc = cx;             §\C{// must be initialized}§
 crc = 7;                                                §\C{// error, cannot change cx}§
 ®&®crc = &cx;                                   §\C{// error, cannot change crc}§
 \end{cfa}
 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}:
 \begin{cfa}
 int & const cr = *0;                    §\C{// where 0 is the int * zero}§
 \end{cfa}
 Note, constant reference-types do not prevent addressing errors because of explicit storage-management:
+const int cx = 5;                                       §\C{// cannot change cx;}§
+const int & cr = cx;                            §\C{// cannot change what cr points to}§
+®&®cr = &cx;                                            §\C{// can change cr}§
+cr = 7;                                                         §\C{// error, cannot change cx}§
+int & const rc = x;                                     §\C{// must be initialized}§
+®&®rc = &x;                                                     §\C{// error, cannot change rc}§
+const int & const crc = cx;                     §\C{// must be initialized}§
+crc = 7;                                                        §\C{// error, cannot change cx}§
+®&®crc = &cx;                                           §\C{// error, cannot change crc}§
+\end{cfa}
+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}:
+\begin{cfa}
+int & const cr = *0;                            §\C{// where 0 is the int * zero}§
+\end{cfa}
+Note, constant reference-types do not prevent \Index{addressing errors} because of explicit storage-management:
 \begin{cfa}
 int & const cr = *malloc();
 cr = 5;
 delete &cr;
 cr = 7;                                                 §\C{// unsound pointer dereference}§
 \end{cfa}
 Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
+free( &cr );
+cr = 7;                                                         §\C{// unsound pointer dereference}§
+\end{cfa}
+The position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers.
 The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations;
 \CFA-style declarations attempt to address this issue:
+\CFA-style declarations (see \VRef{s:Declarations}) attempt to address this issue:
 \begin{quote2}
 \begin{tabular}{@{}l@{\hspace{3em}}l@{}}
 …
 \end{tabular}
 \end{quote2}
+where the \CFA declaration is read left-to-right (see \VRef{s:Declarations}).
+where the \CFA declaration is read left-to-right.
+Finally, like pointers, references are usable and composable with other type operators and generators.
+\begin{cfa}
+int w, x, y, z, & ar[3] = { x, y, z }; §\C{// initialize array of references}§
+&ar[1] = &w;                                            §\C{// change reference array element}§
+typeof( ar[1] ) p;                                      §\C{// (gcc) is int, i.e., the type of referenced object}§
+typeof( &ar[1] ) q;                                     §\C{// (gcc) is int \&, i.e., the type of reference}§
+sizeof( ar[1] ) == sizeof( int );       §\C{// is true, i.e., the size of referenced object}§
+sizeof( &ar[1] ) == sizeof( int *)      §\C{// is true, i.e., the size of a reference}§
+\end{cfa}
 In 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}.
+Also, \CC does not allow \Index{array}s\index{array!reference} of reference\footnote{
+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.}
 \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.
+\subsection{Address-of Semantics}
+In C, ©&E© is an rvalue for any expression ©E©.
+\CFA extends the ©&© (address-of) operator as follows:
+\begin{itemize}
+\item
+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).
+\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).
+\end{itemize}
+The following example shows the first rule applied to different \Index{rvalue} contexts:
+\begin{cfa}
+int x, * px, ** ppx, *** pppx, **** ppppx;
+int & rx = x, && rrx = rx, &&& rrrx = rrx ;
+x = rrrx;               // rrrx is an lvalue with type int &&& (equivalent to x)
+px = &rrrx;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (&x)
+ppx = &&rrrx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (&rx)
+pppx = &&&rrrx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (&rrx)
+ppppx = &&&&rrrx; // starting from &&&rrrx, &&&&rrrx is an rvalue with type int **** (&rrrx)
+\end{cfa}
+The following example shows the second rule applied to different \Index{lvalue} contexts:
+\begin{cfa}
+int x, * px, ** ppx, *** pppx;
+int & rx = x, && rrx = rx, &&& rrrx = rrx ;
+rrrx = 2;               // rrrx is an lvalue with type int &&& (equivalent to x)
+&rrrx = px;             // starting from rrrx, &rrrx is an rvalue with type int *&&& (rx)
+&&rrrx = ppx;   // starting from &rrrx, &&rrrx is an rvalue with type int **&& (rrx)
+&&&rrrx = pppx; // starting from &&rrrx, &&&rrrx is an rvalue with type int ***& (rrrx)
+\end{cfa}
+\subsection{Conversions}
+C provides a basic implicit conversion to simplify variable usage:
+\begin{enumerate}
+\setcounter{enumi}{-1}
+\item
+lvalue to rvalue conversion: ©cv T© converts to ©T©, which allows implicit variable dereferencing.
+\begin{cfa}
+int x;
+x + 1;                  // lvalue variable (int) converts to rvalue for expression
+\end{cfa}
+An rvalue has no type qualifiers (©cv©), so the lvalue qualifiers are dropped.
+\end{enumerate}
+\CFA provides three new implicit conversion for reference types to simplify reference usage.
+\begin{enumerate}
+\item
+reference to rvalue conversion: ©cv T &© converts to ©T©, which allows implicit reference dereferencing.
+\begin{cfa}
+int x, &r = x, f( int p );
+x = ®r® + f( ®r® );  // lvalue reference converts to rvalue
+\end{cfa}
+An rvalue has no type qualifiers (©cv©), so the reference qualifiers are dropped.
+\item
+lvalue to reference conversion: \lstinline[deletekeywords={lvalue}]@lvalue-type cv1 T@ converts to ©cv2 T &©, which allows implicitly converting variables to references.
+\begin{cfa}
+int x, &r = ®x®, f( int & p ); // lvalue variable (int) convert to reference (int &)
+f( ®x® );               // lvalue variable (int) convert to reference (int &)
+\end{cfa}
+Conversion can restrict a type, where ©cv1© $\le$ ©cv2©, \eg passing an ©int© to a ©const volatile int &©, which has low cost.
+Conversion can expand a type, where ©cv1© $>$ ©cv2©, \eg passing a ©const volatile int© to an ©int &©, which has high cost (\Index{warning});
+furthermore, if ©cv1© has ©const© but not ©cv2©, a temporary variable is created to preserve the immutable lvalue.
+\item
+rvalue to reference conversion: ©T© converts to ©cv T &©, which allows binding references to temporaries.
+\begin{cfa}
+int x, & f( int & p );
+f( ®x + 3® );   // rvalue parameter (int) implicitly converts to lvalue temporary reference (int &)
+®&f®(...) = &x; // rvalue result (int &) implicitly converts to lvalue temporary reference (int &)
+\end{cfa}
+In both case, modifications to the temporary are inaccessible (\Index{warning}).
+Conversion expands the temporary-type with ©cv©, which is low cost since the temporary is inaccessible.
+\end{enumerate}
+\subsection{Initialization}
 \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.
 …
 Because 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.
 In contrast, the left-hand side of assignment has an address that has a duality.
+Therefore, for pointer/reference initialization, the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}).
+\begin{cfa}
+int * p = &x;                           §\C{// must have address of x}§
+int & r = x;                            §\C{// must have address of x}§
+\end{cfa}
+Therefore, it is superfluous to require explicitly taking the address of the initialization object, even though the type is incorrect.
+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.
+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.
+(\CFA extends pointer initialization so a variable name is automatically referenced, eliminating the unsafe assignment.)
+Therefore, for pointer/reference initialization, the initializing value must be an address not a value.
+\begin{cfa}
+int * p = &x;                                           §\C{// assign address of x}§
+®int * p = x;®                                          §\C{// assign value of x}§
+int & r = x;                                            §\C{// must have address of x}§
+\end{cfa}
+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).
+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.
+Note, this is strictly a convenience and safety feature for a programmer.
+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.
+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.
 Similarly, 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.
 \begin{cfa}
 int & f( int & r );                             §\C{// reference parameter and return}§
 z = f( x ) + f( y );                    §\C{// reference operator added, temporaries needed for call results}§
+int & f( int & r );                                     §\C{// reference parameter and return}§
+z = f( x ) + f( y );                            §\C{// reference operator added, temporaries needed for call results}§
 \end{cfa}
 Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©r© can be locally reassigned within ©f©.
 …
 z = temp1 + temp2;
 \end{cfa}
 This implicit referencing is crucial for reducing the syntactic burden for programmers when using references;
+This \Index{implicit referencing} is crucial for reducing the syntactic burden for programmers when using references;
 otherwise references have the same syntactic  burden as pointers in these contexts.
 …
 void f( ®const® int & cr );
 void g( ®const® int * cp );
 f( 3 );                   g( &3 );
 f( x + y );             g( &(x + y) );
+f( 3 );                   g( ®&®3 );
+f( x + y );             g( ®&®(x + y) );
 \end{cfa}
 Here, 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.
+(The ©&© is necessary for the pointer-type parameter to make the types match, and is a common requirement for a C programmer.)
+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©).
+Importantly, ©&3© may not be equal to ©&3©, where the references occur across calls because the temporaries maybe different on each call.
 \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{
 If whole program analysis is possible, and shows the parameter is not assigned, \ie it is ©const©, the temporary is unnecessary.}
 …
 void f( int & r );
 void g( int * p );
 f( 3 );                   g( &3 );              §\C{// compiler implicit generates temporaries}§
 f( x + y );             g( &(x + y) );  §\C{// compiler implicit generates temporaries}§
+f( 3 );                   g( ®&®3 );            §\C{// compiler implicit generates temporaries}§
+f( x + y );             g( ®&®(x + y) );        §\C{// compiler implicit generates temporaries}§
 \end{cfa}
 Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{
 …
 %\CFA attempts to handle pointers and references in a uniform, symmetric manner.
 However, C handles routine objects in an inconsistent way.
 A routine object is both a pointer and a reference (particle and wave).
+Finally, C handles \Index{routine object}s in an inconsistent way.
+A routine object is both a pointer and a reference (\Index{particle and wave}).
 \begin{cfa}
 void f( int i );
+void (*fp)( int );
+fp = f;                                                 §\C{// reference initialization}§
+fp = &f;                                                §\C{// pointer initialization}§
+fp = *f;                                                §\C{// reference initialization}§
+fp(3);                                                  §\C{// reference invocation}§
+(*fp)(3);                                               §\C{// pointer invocation}§
+\end{cfa}
+A routine object is best described by a ©const© reference:
+\begin{cfa}
+const void (&fr)( int ) = f;
+fr = ...                                                §\C{// error, cannot change code}§
+&fr = ...;                                              §\C{// changing routine reference}§
+fr( 3 );                                                §\C{// reference call to f}§
+(*fr)(3);                                               §\C{// error, incorrect type}§
+void (*fp)( int );                                      §\C{// routine pointer}§
+fp = f;                                                         §\C{// reference initialization}§
+fp = &f;                                                        §\C{// pointer initialization}§
+fp = *f;                                                        §\C{// reference initialization}§
+fp(3);                                                          §\C{// reference invocation}§
+(*fp)(3);                                                       §\C{// pointer invocation}§
+\end{cfa}
+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.
+Instead, a routine object should be referenced by a ©const© reference:
+\begin{cfa}
+®const® void (®&® fr)( int ) = f;       §\C{// routine reference}§
+fr = ...                                                        §\C{// error, cannot change code}§
+&fr = ...;                                                      §\C{// changing routine reference}§
+fr( 3 );                                                        §\C{// reference call to f}§
+(*fr)(3);                                                       §\C{// error, incorrect type}§
 \end{cfa}
 because the value of the routine object is a routine literal, \ie the routine code is normally immutable during execution.\footnote{
 Dynamic code rewriting is possible but only in special circumstances.}
 \CFA allows this additional use of references for routine objects in an attempt to give a more consistent meaning for them.
-This situation is different from inferring with reference type being used ...
 …
 \section{Named and Default Arguments}
 Named and default arguments~\cite{Hardgrave76}\footnote{
+Named\index{named arguments}\index{arguments!named} and default\index{default arguments}\index{arguments!default} arguments~\cite{Hardgrave76}\footnote{
 Francez~\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.}
 are two mechanisms to simplify routine call.
 …
 hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}).
 All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling.
+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.
 …
+}
 // §\CFA§ safe initialization/copy
+// §\CFA§ safe initialization/copy, i.e., implicit size specification
 forall( dtype T | sized(T) ) T * memset( T * dest, char c );§\indexc{memset}§
 forall( dtype T | sized(T) ) T * memcpy( T * dest, const T * src );§\indexc{memcpy}§
 …
 \leavevmode
 \begin{cfa}[aboveskip=0pt,belowskip=0pt]
+forall( otype T | { int ?<?( T, T ); } )
+T min( T t1, T t2 );§\indexc{min}§
+forall( otype T | { int ?>?( T, T ); } )
+T max( T t1, T t2 );§\indexc{max}§
+forall( otype T | { T min( T, T ); T max( T, T ); } )
+T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
+forall( otype T )
+void swap( T * t1, T * t2 );§\indexc{swap}§
+forall( otype T | { int ?<?( T, T ); } ) T min( T t1, T t2 );§\indexc{min}§
+forall( otype T | { int ?>?( T, T ); } ) T max( T t1, T t2 );§\indexc{max}§
+forall( otype T | { T min( T, T ); T max( T, T ); } ) T clamp( T value, T min_val, T max_val );§\indexc{clamp}§
+forall( otype T ) void swap( T * t1, T * t2 );§\indexc{swap}§
 \end{cfa}

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

Context Navigation

Changeset 46e4440e for doc/user

Legend:

doc/user/user.tex

Download in other formats: