- Timestamp:
- Aug 29, 2016, 10:33:05 AM (9 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- 5e644d3e
- Parents:
- 79841be (diff), 413ad05 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the(diff)
links above to see all the changes relative to each parent. - Location:
- doc
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/LaTeXmacros/common.tex
r79841be r6943a987 11 11 %% Created On : Sat Apr 9 10:06:17 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Tue Aug 2 17:02:02201614 %% Update Count : 2 2813 %% Last Modified On : Sun Aug 14 08:27:29 2016 14 %% Update Count : 231 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 154 154 }% 155 155 \newcommand{\etal}{% 156 \@ifnextchar{.}{\abbrevFont{et 156 \@ifnextchar{.}{\abbrevFont{et~al}}% 157 157 {\abbrevFont{et al}.\xspace}% 158 158 }% … … 255 255 literate={-}{\raisebox{-0.15ex}{\texttt{-}}}1 {^}{\raisebox{0.6ex}{$\scriptscriptstyle\land\,$}}1 256 256 {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 {_}{\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}1 {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1 257 {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2 {...}{$\dots$}2,257 {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2, 258 258 }% 259 259 -
doc/aaron_comp_II/comp_II.tex
r79841be r6943a987 91 91 \CFA\footnote{Pronounced ``C-for-all'', and written \CFA or \CFL.} is an evolutionary modernization of the C programming language currently being designed and built at the University of Waterloo by a team led by Peter Buhr. 92 92 \CFA both fixes existing design problems and adds multiple new features to C, including name overloading, user-defined operators, parametric-polymorphic routines, and type constructors and destructors, among others. 93 The new features make \CFA significantly more powerful and expressive than C, but impose a significant compile-time cost, particularly in the expression resolver, which must evaluate the typing rules of a muchmore complex type-system.93 The new features make \CFA more powerful and expressive than C, but impose a compile-time cost, particularly in the expression resolver, which must evaluate the typing rules of a significantly more complex type-system. 94 94 95 95 The primary goal of this research project is to develop a sufficiently performant expression resolution algorithm, experimentally validate its performance, and integrate it into CFA, the \CFA reference compiler. … … 104 104 105 105 It is important to note that \CFA is not an object-oriented language. 106 \CFA does have a system of (possibly implicit) type conversions derived from C's type conversions; while these conversions may be thought of as something like an inheritance hierarchy the underlying semantics are significantly different and such an analogy is loose at best.106 \CFA does have a system of (possibly implicit) type conversions derived from C's type conversions; while these conversions may be thought of as something like an inheritance hierarchy, the underlying semantics are significantly different and such an analogy is loose at best. 107 107 Particularly, \CFA has no concept of ``subclass'', and thus no need to integrate an inheritance-based form of polymorphism with its parametric and overloading-based polymorphism. 108 108 The graph structure of the \CFA type conversions is also markedly different than an inheritance graph; it has neither a top nor a bottom type, and does not satisfy the lattice properties typical of inheritance graphs. … … 120 120 \end{lstlisting} 121 121 The ©identity© function above can be applied to any complete object type (or ``©otype©''). 122 The type variable ©T© is transformed into a set of additional implicit parameters to ©identity© which encode sufficient information about ©T© to create and return a variable of that type.122 The type variable ©T© is transformed into a set of additional implicit parameters to ©identity©, which encode sufficient information about ©T© to create and return a variable of that type. 123 123 The current \CFA implementation passes the size and alignment of the type represented by an ©otype© parameter, as well as an assignment operator, constructor, copy constructor and destructor. 124 124 Here, the runtime cost of polymorphism is spread over each polymorphic call, due to passing more arguments to polymorphic functions; preliminary experiments have shown this overhead to be similar to \CC virtual function calls. 125 125 Determining if packaging all polymorphic arguments to a function into a virtual function table would reduce the runtime overhead of polymorphic calls is an open research question. 126 126 127 Since bare polymorphic types do not provide a great range of available operations, \CFA alsoprovides a \emph{type assertion} mechanism to provide further information about a type:127 Since bare polymorphic types do not provide a great range of available operations, \CFA provides a \emph{type assertion} mechanism to provide further information about a type: 128 128 \begin{lstlisting} 129 129 forall(otype T ®| { T twice(T); }®) … … 137 137 \end{lstlisting} 138 138 These type assertions may be either variable or function declarations that depend on a polymorphic type variable. 139 ©four_times© can only be called with an argument for which there exists a function named ©twice© that can take that argument and return another value of the same type; a pointer to the appropriate ©twice© function is passed as an additional implicit parameter to the call to©four_times©.139 ©four_times© can only be called with an argument for which there exists a function named ©twice© that can take that argument and return another value of the same type; a pointer to the appropriate ©twice© function is passed as an additional implicit parameter to the call of ©four_times©. 140 140 141 141 Monomorphic specializations of polymorphic functions can themselves be used to satisfy type assertions. … … 148 148 The compiler accomplishes this by creating a wrapper function calling ©twice // (2)© with ©S© bound to ©double©, then providing this wrapper function to ©four_times©\footnote{©twice // (2)© could also have had a type parameter named ©T©; \CFA specifies renaming of the type parameters, which would avoid the name conflict with the type variable ©T© of ©four_times©.}. 149 149 150 Finding appropriate functions to satisfy type assertions is essentially a recursive case of expression resolution, as it takes a name (that of the type assertion) and attempts to match it to a suitable declaration in the current scope.150 Finding appropriate functions to satisfy type assertions is essentially a recursive case of expression resolution, as it takes a name (that of the type assertion) and attempts to match it to a suitable declaration \emph{in the current scope}. 151 151 If a polymorphic function can be used to satisfy one of its own type assertions, this recursion may not terminate, as it is possible that function is examined as a candidate for its own type assertion unboundedly repeatedly. 152 152 To avoid infinite loops, the current CFA compiler imposes a fixed limit on the possible depth of recursion, similar to that employed by most \CC compilers for template expansion; this restriction means that there are some semantically well-typed expressions that cannot be resolved by CFA. … … 170 170 forall(otype M | has_magnitude(M)) 171 171 M max_magnitude( M a, M b ) { 172 M aa = abs(a), ab = abs(b); 173 return aa < ab ? b : a; 172 return abs(a) < abs(b) ? b : a; 174 173 } 175 174 \end{lstlisting} 176 175 177 176 Semantically, traits are simply a named lists of type assertions, but they may be used for many of the same purposes that interfaces in Java or abstract base classes in \CC are used for. 178 Unlike Java interfaces or \CC base classes, \CFA types do not explicitly state any inheritance relationship to traits they satisfy; this can be considered a form of structural inheritance, similar to i nterface implementationin Go, as opposed to the nominal inheritance model of Java and \CC.177 Unlike Java interfaces or \CC base classes, \CFA types do not explicitly state any inheritance relationship to traits they satisfy; this can be considered a form of structural inheritance, similar to implementation of an interface in Go, as opposed to the nominal inheritance model of Java and \CC. 179 178 Nominal inheritance can be simulated with traits using marker variables or functions: 180 179 \begin{lstlisting} … … 190 189 \end{lstlisting} 191 190 192 Traits, however, are significantly more powerful than nominal-inheritance interfaces; firstly, due to the scoping rules of the declarations whichsatisfy a trait's type assertions, a type may not satisfy a trait everywhere that the type is declared, as with ©char© and the ©nominal© trait above.193 Secondly, traits may be used to declare a relationship between multiple types, a property whichmay be difficult or impossible to represent in nominal-inheritance type systems:191 Traits, however, are significantly more powerful than nominal-inheritance interfaces; firstly, due to the scoping rules of the declarations that satisfy a trait's type assertions, a type may not satisfy a trait everywhere that the type is declared, as with ©char© and the ©nominal© trait above. 192 Secondly, traits may be used to declare a relationship among multiple types, a property that may be difficult or impossible to represent in nominal-inheritance type systems: 194 193 \begin{lstlisting} 195 194 trait pointer_like(®otype Ptr, otype El®) { … … 202 201 }; 203 202 204 typedef list *list_iterator;203 typedef list *list_iterator; 205 204 206 205 lvalue int *?( list_iterator it ) { … … 209 208 \end{lstlisting} 210 209 211 In the example above, ©(list_iterator, int)© satisfies ©pointer_like© by the given function, and ©(list_iterator, list)© also satisfies ©pointer_like© by the built-in pointer dereference operator. 210 In the example above, ©(list_iterator, int)© satisfies ©pointer_like© by the user-defined dereference function, and ©(list_iterator, list)© also satisfies ©pointer_like© by the built-in dereference operator for pointers. 211 Given a declaration ©list_iterator it©, ©*it© can be either an ©int© or a ©list©, with the meaning disambiguated by context (\eg ©int x = *it;© interprets ©*it© as an ©int©, while ©(*it).value = 42;© interprets ©*it© as a ©list©). 212 212 While a nominal-inheritance system with associated types could model one of those two relationships by making ©El© an associated type of ©Ptr© in the ©pointer_like© implementation, few such systems could model both relationships simultaneously. 213 213 214 The flexibility of \CFA's implicit trait 215 The ability of types to begin to or cease to satisfy traits when declarations go into or out of scope makes caching of trait satisfaction judgements difficult, and the ability of traits to take multiple type parameters c ouldlead to a combinatorial explosion of work in any attempt to pre-compute trait satisfaction relationships.214 The flexibility of \CFA's implicit trait-satisfaction mechanism provides programmers with a great deal of power, but also blocks some optimization approaches for expression resolution. 215 The ability of types to begin to or cease to satisfy traits when declarations go into or out of scope makes caching of trait satisfaction judgements difficult, and the ability of traits to take multiple type parameters can lead to a combinatorial explosion of work in any attempt to pre-compute trait satisfaction relationships. 216 216 On the other hand, the addition of a nominal inheritance mechanism to \CFA's type system or replacement of \CFA's trait satisfaction system with a more object-oriented inheritance model and investigation of possible expression resolution optimizations for such a system may be an interesting avenue of further research. 217 217 218 218 \subsection{Name Overloading} 219 219 In C, no more than one variable or function in the same scope may share the same name\footnote{Technically, C has multiple separated namespaces, one holding ©struct©, ©union©, and ©enum© tags, one holding labels, one holding typedef names, variable, function, and enumerator identifiers, and one for each ©struct© or ©union© type holding the field names.}, and variable or function declarations in inner scopes with the same name as a declaration in an outer scope hide the outer declaration. 220 This makes finding the proper declaration to match to a variable expression or function application a simple matter of symboltable lookup, which can be easily and efficiently implemented.220 This restriction makes finding the proper declaration to match to a variable expression or function application a simple matter of symbol-table lookup, which can be easily and efficiently implemented. 221 221 \CFA, on the other hand, allows overloading of variable and function names, so long as the overloaded declarations do not have the same type, avoiding the multiplication of variable and function names for different types common in the C standard library, as in the following example: 222 222 \begin{lstlisting} … … 229 229 double max = DBL_MAX; // (4) 230 230 231 max(7, -max); // uses (1) and (3), by matching int type of 7232 max(max, 3.14); // uses (2) and (4), by matching double type of 3.14231 max(7, -max); // uses (1) and (3), by matching int type of the constant 7 232 max(max, 3.14); // uses (2) and (4), by matching double type of the constant 3.14 233 233 234 234 max(max, -max); // ERROR: ambiguous 235 int m = max(max, -max); // uses (1) and (3) twice, byreturn type235 int m = max(max, -max); // uses (1) once and (3) twice, by matching return type 236 236 \end{lstlisting} 237 237 … … 239 239 240 240 \subsection{Implicit Conversions} 241 In addition to the multiple interpretations of an expression produced by name overloading, \CFA also supports all of the implicit conversions present in C, producing further candidate interpretations for expressions.242 C does not have a traditionally-definedinheritance hierarchy of types, but the C standard's rules for the ``usual arithmetic conversions'' define which of the built-in types are implicitly convertable to which other types, and the relative cost of any pair of such conversions from a single source type.243 \CFA adds to the usual arithmetic conversions rules for determining the cost of binding a polymorphic type variable in a function call; such bindings are cheaper than any \emph{unsafe} (narrowing) conversion, \eg ©int© to ©char©, but more expensive than any \emph{safe} (widening) conversion, \eg ©int© to ©double©.244 245 The expression resolution problem, then, is to find the unique minimal-cost interpretation of each expression in the program, where all identifiers must be matched to a declaration and implicit conversions or polymorphic bindings of the result of an expression may increase the cost of the expression.241 In addition to the multiple interpretations of an expression produced by name overloading, \CFA must support all of the implicit conversions present in C for backward compatibility, producing further candidate interpretations for expressions. 242 C does not have a inheritance hierarchy of types, but the C standard's rules for the ``usual arithmetic conversions'' define which of the built-in types are implicitly convertable to which other types, and the relative cost of any pair of such conversions from a single source type. 243 \CFA adds to the usual arithmetic conversions rules defining the cost of binding a polymorphic type variable in a function call; such bindings are cheaper than any \emph{unsafe} (narrowing) conversion, \eg ©int© to ©char©, but more expensive than any \emph{safe} (widening) conversion, \eg ©int© to ©double©. 244 245 The expression resolution problem, then, is to find the unique minimal-cost interpretation of each expression in the program, where all identifiers must be matched to a declaration, and implicit conversions or polymorphic bindings of the result of an expression may increase the cost of the expression. 246 246 Note that which subexpression interpretation is minimal-cost may require contextual information to disambiguate. 247 For instance, in the example in the previous subsection, ©max(max, -max)© cannot be unambiguously resolved, but ©int m = max(max, -max) ;© has a single minimal-cost resolution.248 ©int m = (int)max((double)max, -(double)max)© is also be a valid interpretation, but is not minimal-cost due to the unsafe cast from the ©double© result of ©max© to ©int© (the two ©double© casts function as type ascriptions selecting ©double max© rather than casts from ©int max© to ©double©, and as such are zero-cost).247 For instance, in the example in the previous subsection, ©max(max, -max)© cannot be unambiguously resolved, but ©int m = max(max, -max)© has a single minimal-cost resolution. 248 While the interpretation ©int m = (int)max((double)max, -(double)max)© is also a valid interpretation, it is not minimal-cost due to the unsafe cast from the ©double© result of ©max© to ©int© (the two ©double© casts function as type ascriptions selecting ©double max© rather than casts from ©int max© to ©double©, and as such are zero-cost). 249 249 250 250 \subsubsection{User-generated Implicit Conversions} … … 252 252 Such a conversion system should be simple for programmers to utilize, and fit naturally with the existing design of implicit conversions in C; ideally it would also be sufficiently powerful to encode C's usual arithmetic conversions itself, so that \CFA only has one set of rules for conversions. 253 253 254 Ditchfield~\cite{Ditchfield:conversions} haslaid out a framework for using polymorphic-conversion-constructor functions to create a directed acyclic graph (DAG) of conversions.254 Ditchfield~\cite{Ditchfield:conversions} laid out a framework for using polymorphic-conversion-constructor functions to create a directed acyclic graph (DAG) of conversions. 255 255 A monomorphic variant of these functions can be used to mark a conversion arc in the DAG as only usable as the final step in a conversion. 256 With these two types of conversion arcs, separate DAGs can be created for the safe and the unsafe conversions, and conversion cost can be represented as path length through the DAG.256 With these two types of conversion arcs, separate DAGs can be created for the safe and the unsafe conversions, and conversion cost can be represented the length of the shortest path through the DAG from one type to another. 257 257 \begin{figure}[h] 258 258 \centering 259 259 \includegraphics{conversion_dag} 260 \caption{A portion of the implicit conversion DAG for built-in types.} 260 \caption{A portion of the implicit conversion DAG for built-in types.}\label{fig:conv_dag} 261 261 \end{figure} 262 As can be seen in the example DAG above, there are either safe or unsafe paths between each of the arithmetic types listed; the ``final'' arcs are important both to avoid creating cycles in the signed-unsigned conversions, and to disambiguate potential diamond conversions (\eg, if the ©int© to ©unsigned int© conversion was not marked final there would be two length-two paths from ©int© to ©unsigned long©, and it would beimpossible to choose which one; however, since the ©unsigned int© to ©unsigned long© arc can not be traversed after the final ©int© to ©unsigned int© arc, there is a single unambiguous conversion path from ©int© to ©unsigned long©).262 As can be seen in Figure~\ref{fig:conv_dag}, there are either safe or unsafe paths between each of the arithmetic types listed; the ``final'' arcs are important both to avoid creating cycles in the signed-unsigned conversions, and to disambiguate potential diamond conversions (\eg, if the ©int© to ©unsigned int© conversion was not marked final there would be two length-two paths from ©int© to ©unsigned long©, making it impossible to choose which one; however, since the ©unsigned int© to ©unsigned long© arc can not be traversed after the final ©int© to ©unsigned int© arc, there is a single unambiguous conversion path from ©int© to ©unsigned long©). 263 263 264 264 Open research questions on this topic include: 265 265 \begin{itemize} 266 266 \item Can a conversion graph be generated that represents each allowable conversion in C with a unique minimal-length path such that the path lengths accurately represent the relative costs of the conversions? 267 \item Can such a graph representation canbe usefully augmented to include user-defined types as well as built-in types?268 \item Can the graph canbe efficiently represented and used in the expression resolver?267 \item Can such a graph representation be usefully augmented to include user-defined types as well as built-in types? 268 \item Can the graph be efficiently represented and used in the expression resolver? 269 269 \end{itemize} 270 270 271 271 \subsection{Constructors and Destructors} 272 272 Rob Shluntz, a current member of the \CFA research team, has added constructors and destructors to \CFA. 273 Each type has an overridable default-generated zero-argument constructor, copy constructor, assignment operator, and destructor; for ©struct© types these functions each call their equivalents on each field of the ©struct©. 274 This affects expression resolution because an ©otype© type variable ©T© implicitly adds four type assertions, one for each of these four functions, so assertion resolution is pervasive in \CFA polymorphic functions, even those without any explicit type assertions. 273 Each type has an overridable default-generated zero-argument constructor, copy constructor, assignment operator, and destructor. 274 For ©struct© types these functions each call their equivalents on each field of the ©struct©. 275 This feature affects expression resolution because an ©otype© type variable ©T© implicitly adds four type assertions, one for each of these four functions, so assertion resolution is pervasive in \CFA polymorphic functions, even those without any explicit type assertions. 275 276 The following example shows the implicitly-generated code in green: 276 277 \begin{lstlisting} … … 280 281 }; 281 282 282 ¢void ?{}(kv *this) { 283 ?{}(& this->key);284 ?{}(& this->value);285 } 286 void ?{}(kv *this, kv that) { 287 ?{}(& this->key, that.key);288 ?{}(& this->value, that.value);289 } 290 kv ?=?(kv *this, kv that) { 291 ?=?(& this->key, that.key);292 ?=?(& this->value, that.value);283 ¢void ?{}(kv *this) { // default constructor 284 ?{}(&(this->key)); // call recursively on members 285 ?{}(&(this->value)); 286 } 287 void ?{}(kv *this, kv that) { // copy constructor 288 ?{}(&(this->key), that.key); 289 ?{}(&(this->value), that.value); 290 } 291 kv ?=?(kv *this, kv that) { // assignment operator 292 ?=?(&(this->key), that.key); 293 ?=?(&(this->value), that.value); 293 294 return *this; 294 295 } 295 void ^?{}(kv *this) { 296 ^?{}(& this->key);297 ^?{}(& this->value);296 void ^?{}(kv *this) { // destructor 297 ^?{}(&(this->key)); 298 ^?{}(&(this->value)); 298 299 }¢ 299 300 … … 335 336 \begin{itemize} 336 337 \item Since there is an implicit conversion from ©void*© to any pointer type, the highlighted expression can be interpreted as either a ©void*©, matching ©f // (1)©, or a ©box(S)*© for some type ©S©, matching ©f // (2)©. 337 \item To determine the cost of the ©box(S)© interpretation, a type must be found for ©S© whichsatisfies the ©otype© implicit type assertions (assignment operator, default and copy constructors, and destructor); one option is ©box(S2)© for some type ©S2©.338 \item To determine the cost of the ©box(S)© interpretation, a type must be found for ©S© that satisfies the ©otype© implicit type assertions (assignment operator, default and copy constructors, and destructor); one option is ©box(S2)© for some type ©S2©. 338 339 \item The assignment operator, default and copy constructors, and destructor of ©box(T)© are also polymorphic functions, each of which require the type parameter ©T© to have an assignment operator, default and copy constructors, and destructor. When choosing an interpretation for ©S2©, one option is ©box(S3)©, for some type ©S3©. 339 340 \item The previous step repeats until stopped, with four times as much work performed at each step. 340 341 \end{itemize} 341 This problem can occur in any resolution context where a polymorphic function that can satisfy its own type assertions is required for a possible interpretation of an expression with no constraints on its type, and is thus not limited to combinations of generic types with ©void*© conversions, though constructors for generic types often satisfy their own assertions and a polymorphic conversion such as the ©void*© conversion to a polymorphic variable can create an expression with no constraints on its type. 342 This problem can occur in any resolution context where a polymorphic function can satisfy its own type assertions is required for a possible interpretation of an expression with no constraints on its type, and is thus not limited to combinations of generic types with ©void*© conversions. 343 However, constructors for generic types often satisfy their own assertions and a polymorphic conversion such as the ©void*© conversion to a polymorphic variable is a common way to create an expression with no constraints on its type. 342 344 As discussed above, the \CFA expression resolver must handle this possible infinite recursion somehow, and it occurs fairly naturally in code like the above that uses generic types. 343 345 … … 345 347 \CFA adds \emph{tuple types} to C, a syntactic facility for referring to lists of values anonymously or with a single identifier. 346 348 An identifier may name a tuple, and a function may return one. 347 Particularly relevantly for resolution, a tuple may be implicitly \emph{destructured} into a list of values, as in the call to ©swap© below:348 \begin{lstlisting} 349 [char, char] x = [ '!', '?' ]; 350 int x = 42; 351 352 forall(otype T) [T, T] swap( T a, T b ) { return [b, a]; } 349 Particularly relevantly for resolution, a tuple may be implicitly \emph{destructured} into a list of values, as in the call to ©swap©: 350 \begin{lstlisting} 351 [char, char] x = [ '!', '?' ]; // (1) 352 int x = 42; // (2) 353 354 forall(otype T) [T, T] swap( T a, T b ) { return [b, a]; } // (3) 353 355 354 356 x = swap( x ); // destructure [char, char] x into two elements of parameter list 355 357 // cannot use int x for parameter, not enough arguments to swap 356 \end{lstlisting} 357 Tuple destructuring means that the mapping from the position of a subexpression in the argument list to the position of a paramter in the function declaration is not straightforward, as some arguments may be expandable to different numbers of parameters, like ©x© above. 358 359 void swap( int, char, char ); // (4) 360 361 swap( x, x ); // resolved as (4) on (2) and (1) 362 // (3) on (2) and (2) is close, but the polymorphic binding makes it not minimal-cost 363 \end{lstlisting} 364 Tuple destructuring means that the mapping from the position of a subexpression in the argument list to the position of a paramter in the function declaration is not straightforward, as some arguments may be expandable to different numbers of parameters, like ©x© above. 365 In the second example, the second ©x© argument can be resolved starting at the second or third parameter of ©swap©, depending which interpretation of ©x© was chosen for the first argument. 358 366 359 367 \subsection{Reference Types} 360 368 I have been designing \emph{reference types} for \CFA, in collaboration with the rest of the \CFA research team. 361 369 Given some type ©T©, a ©T&© (``reference to ©T©'') is essentially an automatically dereferenced pointer; with these semantics most of the C standard's discussions of lvalues can be expressed in terms of references instead, with the benefit of being able to express the difference between the reference and non-reference version of a type in user code. 362 References preserve C's existing qualifier-dropping lvalue-to-rvalue conversion (\eg a ©const volatile int&© can be implicitly converted to a bare ©int©); the reference proposal also adds a rvalue-to-lvalue conversion to \CFA, implemented by storing the value in a new compiler-generated temporary and passing a reference to the temporary. 363 These two conversions can chain, producing a qualifier-dropping conversion for references, for instance converting a reference to a ©const int© into a reference to a non-©const int© by copying the originally refered to value into a fresh temporary and taking a reference to this temporary, as below: 370 References preserve C's existing qualifier-dropping lvalue-to-rvalue conversion (\eg a ©const volatile int&© can be implicitly converted to a bare ©int©). 371 The reference proposal also adds a rvalue-to-lvalue conversion to \CFA, implemented by storing the value in a new compiler-generated temporary and passing a reference to the temporary. 372 These two conversions can chain, producing a qualifier-dropping conversion for references, for instance converting a reference to a ©const int© into a reference to a non-©const int© by copying the originally refered to value into a fresh temporary and taking a reference to this temporary, as in: 364 373 \begin{lstlisting} 365 374 const int magic = 42; … … 369 378 print_inc( magic ); // legal; implicitly generated code in green below: 370 379 371 ¢int tmp = magic;¢ // copiesto safely strip const-qualifier380 ¢int tmp = magic;¢ // to safely strip const-qualifier 372 381 ¢print_inc( tmp );¢ // tmp is incremented, magic is unchanged 373 382 \end{lstlisting} 374 These reference conversions may also chain with the other implicit type 375 The main implication of th is for expression resolution is the multiplication of available implicit conversions, though in a restricted context that may be able to be treated efficiently as a special case.383 These reference conversions may also chain with the other implicit type-conversions. 384 The main implication of the reference conversions for expression resolution is the multiplication of available implicit conversions, though given the restricted context reference conversions may be able to be treated efficiently as a special case of implicit conversions. 376 385 377 386 \subsection{Special Literal Types} 378 387 Another proposal currently under consideration for the \CFA type-system is assigning special types to the literal values ©0© and ©1©. 379 Implicit conversions from these types allow ©0© and ©1© to be considered as values of many different types, depending on context, allowing expression desugarings like ©if ( x ) {}© $\Rightarrow$ ©if ( x != 0 ) {}© to be implemented efficiently and preci cely.388 Implicit conversions from these types allow ©0© and ©1© to be considered as values of many different types, depending on context, allowing expression desugarings like ©if ( x ) {}© $\Rightarrow$ ©if ( x != 0 ) {}© to be implemented efficiently and precisely. 380 389 This approach is a generalization of C's existing behaviour of treating ©0© as either an integer zero or a null pointer constant, and treating either of those values as boolean false. 381 390 The main implication for expression resolution is that the frequently encountered expressions ©0© and ©1© may have a large number of valid interpretations. … … 386 395 int somefn(char) = delete; 387 396 \end{lstlisting} 388 This feature is typically used in \CCeleven to make a type non-copyable by deleting its copy constructor and assignment operator , or forbidding some interpretations of a polymorphic function by specifically deleting the forbidden overloads.389 To add a similar feature to \CFA would involve including the deleted function declarations in expression resolution along with the normal declarations, but producing a compiler error if the deleted function was the best resolution.397 This feature is typically used in \CCeleven to make a type non-copyable by deleting its copy constructor and assignment operator\footnote{In previous versions of \CC a type could be made non-copyable by declaring a private copy constructor and assignment operator, but not defining either. This idiom is well-known, but depends on some rather subtle and \CC-specific rules about private members and implicitly-generated functions; the deleted-function form is both clearer and less verbose.}, or forbidding some interpretations of a polymorphic function by specifically deleting the forbidden overloads\footnote{Specific polymorphic function overloads can also be forbidden in previous \CC versions through use of template metaprogramming techniques, though this advanced usage is beyond the skills of many programmers. A similar effect can be produced on an ad-hoc basis at the appropriate call sites through use of casts to determine the function type. In both cases, the deleted-function form is clearer and more concise.}. 398 To add a similar feature to \CFA involves including the deleted function declarations in expression resolution along with the normal declarations, but producing a compiler error if the deleted function is the best resolution. 390 399 How conflicts should be handled between resolution of an expression to both a deleted and a non-deleted function is a small but open research question. 391 400 … … 404 413 %TODO: look up and lit review 405 414 The second area of investigation is minimizing dependencies between argument-parameter matches; the current CFA compiler attempts to match entire argument combinations against functions at once, potentially attempting to match the same argument against the same parameter multiple times. 406 Whether the feature set of \CFA admits an expression resolution algorithm where arguments can be matched to parameters independently of other arguments in the same function application is an area of open research; polymorphic type paramters produce enough of a cross-argument dependencythat the problem is not trivial.415 Whether the feature set of \CFA admits an expression resolution algorithm where arguments can be matched to parameters independently of other arguments in the same function application is an area of open research; polymorphic type paramters produce enough cross-argument dependencies that the problem is not trivial. 407 416 If cross-argument resolution dependencies cannot be completely eliminated, effective caching strategies to reduce duplicated work between equivalent argument-parameter matches in different combinations may mitigate the asymptotic defecits of the whole-combination matching approach. 408 417 The final area of investigation is heuristics and algorithmic approaches to reduce the number of argument interpretations considered in the common case; if argument-parameter matches cannot be made independent, even small reductions in $i$ should yield significant reductions in the $i^{p+1}$ resolver runtime factor. … … 412 421 413 422 \subsection{Argument-Parameter Matching} 414 The first axis for consideration is argument-parameter matching direction --- whether the type matching for a candidate function to a set of candidate arguments is directed by the argument types or the parameter types.423 The first axis for consideration is the argument-parameter matching direction --- whether the type matching for a candidate function to a set of candidate arguments is directed by the argument types or the parameter types. 415 424 For programming languages without implicit conversions, argument-parameter matching is essentially the entirety of the expression resolution problem, and is generally referred to as ``overload resolution'' in the literature. 416 All expression resolution algorithms form a DAG of interpretations, some explicitly, some implicitly; in this DAG, arcs point from function-call interpretations to argument interpretations, as below:425 All expression-resolution algorithms form a DAG of interpretations, some explicitly, some implicitly; in this DAG, arcs point from function-call interpretations to argument interpretations, as in Figure~\ref{fig:res_dag}: 417 426 \begin{figure}[h] 418 427 \centering … … 433 442 \end{figure} 434 443 435 Note that some interpretations may be part of more than one super-interpretation, as with $p_i$ in the bottom row, while some valid subexpression interpretations, like $f_d$ in the middle row, are not used in any interpretation of their containingexpression.444 Note that some interpretations may be part of more than one super-interpretation, as with the second $p_i$ in the bottom row, while some valid subexpression interpretations, like $f_d$ in the middle row, are not used in any interpretation of their superexpression. 436 445 437 446 \subsubsection{Argument-directed (Bottom-up)} … … 451 460 A reasonable hybrid approach might take a top-down approach when the expression to be matched has a fixed type, and a bottom-up approach in untyped contexts. 452 461 This approach may involve switching from one type to another at different levels of the expression tree. 453 For instance :462 For instance, in: 454 463 \begin{lstlisting} 455 464 forall(otype T) … … 460 469 int x = f( f( '!' ) ); 461 470 \end{lstlisting} 462 The outer call to ©f© must have a return type that is (implicitly convertable to) ©int©, so a top-down approach is used to select \textit{(1)} as the proper interpretation of ©f©. \textit{(1)}'s parameter ©x©, however, is an unbound type variable, and can thus take a value of any complete type, providing no guidance for the choice of candidate for the inner call to ©f©. The leaf expression ©'!'©, however, determines a zero-cost interpretation of the inner ©f© as \textit{(2)}, providing a minimal-cost expression resolution where ©T© is bound to ©void*©. 463 464 Deciding when to switch between bottom-up and top-down resolution to minimize wasted work in a hybrid algorithm is a necessarily heuristic process, and though finding good heuristics for which subexpressions to swich matching strategies on is an open question, one reasonable approach might be to set a threshold $t$ for the number of candidate functions, and to use top-down resolution for any subexpression with fewer than $t$ candidate functions, to minimize the number of unmatchable argument interpretations computed, but to use bottom-up resolution for any subexpression with at least $t$ candidate functions, to reduce duplication in argument interpretation computation between the different candidate functions. 471 the outer call to ©f© must have a return type that is (implicitly convertable to) ©int©, so a top-down approach is used to select \textit{(1)} as the proper interpretation of ©f©. \textit{(1)}'s parameter ©x©, however, is an unbound type variable, and can thus take a value of any complete type, providing no guidance for the choice of candidate for the inner call to ©f©. The leaf expression ©'!'©, however, determines a zero-cost interpretation of the inner ©f© as \textit{(2)}, providing a minimal-cost expression resolution where ©T© is bound to ©void*©. 472 473 Deciding when to switch between bottom-up and top-down resolution to minimize wasted work in a hybrid algorithm is a necessarily heuristic process, and finding good heuristics for which subexpressions to swich matching strategies on is an open question. 474 One reasonable approach might be to set a threshold $t$ for the number of candidate functions, and to use top-down resolution for any subexpression with fewer than $t$ candidate functions, to minimize the number of unmatchable argument interpretations computed, but to use bottom-up resolution for any subexpression with at least $t$ candidate functions, to reduce duplication in argument interpretation computation between the different candidate functions. 465 475 466 476 Ganzinger and Ripken~\cite{Ganzinger80} propose an approach (later refined by Pennello~\etal~\cite{Pennello80}) that uses a top-down filtering pass followed by a bottom-up filtering pass to reduce the number of candidate interpretations; they prove that for the Ada programming language a small number of such iterations is sufficient to converge to a solution for the expression resolution problem. 467 477 Persch~\etal~\cite{PW:overload} developed a similar two-pass approach where the bottom-up pass is followed by the top-down pass. 468 These algorithms differ from the hybrid approach under investigation in that they take multiple passes over the expression tree to yield a solution, and also in that theyapply both filtering heuristics to all expression nodes; \CFA's polymorphic functions and implicit conversions make the approach of filtering out invalid types taken by all of these algorithms infeasible.478 These algorithms differ from the hybrid approach under investigation in that they take multiple passes over the expression tree to yield a solution, and that they also apply both filtering heuristics to all expression nodes; \CFA's polymorphic functions and implicit conversions make the approach of filtering out invalid types taken by all of these algorithms infeasible. 469 479 470 480 \subsubsection{Common Subexpression Caching} … … 480 490 \CC~\cite{ANSI98:C++} includes both name overloading and implicit conversions in its expression resolution specification, though unlike \CFA it does complete type-checking on a generated monomorphization of template functions, where \CFA simply checks a list of type constraints. 481 491 The upcoming Concepts standard~\cite{C++concepts} defines a system of type constraints similar in principle to \CFA's. 482 Cormack and Wright~\cite{Cormack90} present an algorithm whichintegrates overload resolution with a polymorphic type inference approach very similar to \CFA's.492 Cormack and Wright~\cite{Cormack90} present an algorithm that integrates overload resolution with a polymorphic type inference approach very similar to \CFA's. 483 493 However, their algorithm does not account for implicit conversions other than polymorphic type binding and their discussion of their overload resolution algorithm is not sufficiently detailed to classify it with the other argument-parameter matching approaches\footnote{Their overload resolution algorithm is possibly a variant of Ganzinger and Ripken~\cite{Ganzinger80} or Pennello~\etal~\cite{Pennello80}, modified to allow for polymorphic type binding.}. 484 494 … … 486 496 Bilson does account for implicit conversions in his algorithm, but it is unclear if the approach is optimal. 487 497 His algorithm integrates checking for valid implicit conversions into the argument-parameter-matching step, essentially trading more expensive matching for a smaller number of argument interpretations. 488 This approach may result in the same subexpression being checked for a type match with the same type multiple times, though again memoization may mitigate this cost, and this approach does not generate implicit conversions that are not useful to match the containing function. 489 Calculating implicit conversions on parameters pairs naturally with a top-down approach to expression resolution, though it can also be used in a bottom-up approach, as Bilson demonstrates. 498 This approach may result in the same subexpression being checked for a type match with the same type multiple times, though again memoization may mitigate this cost; however, this approach does not generate implicit conversions that are not useful to match the containing function. 490 499 491 500 \subsubsection{On Arguments} 492 501 Another approach is to generate a set of possible implicit conversions for each set of interpretations of a given argument. 493 502 This approach has the benefit of detecting ambiguous interpretations of arguments at the level of the argument rather than its containing call, never finds more than one interpretation of the argument with a given type, and re-uses calculation of implicit conversions between function candidates. 494 On the other hand, this approach may unncessarily generate argument interpretations that never match any parameter, wasting work. 495 Further, in the presence of tuple types this approach may lead to a combinatorial explosion of argument interpretations considered, unless the tuple can be considered as a sequence of elements rather than a unified whole. 496 Calculating implicit conversions on arguments is a viable approach for bottom-up expression resolution, though it may be difficult to apply in a top-down approach due to the presence of a target type for the expression interpretation. 503 On the other hand, this approach may unnecessarily generate argument interpretations that never match any parameter, wasting work. 504 Furthermore, in the presence of tuple types, this approach may lead to a combinatorial explosion of argument interpretations considered, unless the tuple can be considered as a sequence of elements rather than a unified whole. 497 505 498 506 \subsection{Candidate Set Generation} 499 All the algorithms discussed to this point generate the complete set of candidate argument interpretations before attempting to match the containing function 500 However, given that the top-level expression interpretation that is ultimately chosen is the minimal-cost valid interpretation, any consideration of non-minimal-cost interpretations is in some sensewasted work.501 Under the assumption that thatprogrammers generally write function calls with relatively low-cost interpretations, a possible work-saving heuristic is to generate only the lowest-cost argument interpretations first, attempt to find a valid top-level interpretation using them, and only if that fails generate the next higher-cost argument interpretations.507 All the algorithms discussed to this point generate the complete set of candidate argument interpretations before attempting to match the containing function-call expression. 508 However, given that the top-level expression interpretation that is ultimately chosen is the minimal-cost valid interpretation, any consideration of non-minimal-cost interpretations is wasted work. 509 Under the assumption that programmers generally write function calls with relatively low-cost interpretations, a possible work-saving heuristic is to generate only the lowest-cost argument interpretations first, attempt to find a valid top-level interpretation using them, and only if that fails generate the next higher-cost argument interpretations. 502 510 503 511 \subsubsection{Eager} … … 563 571 This comparison closes Baker's open research question, as well as potentially improving Bilson's \CFA compiler. 564 572 565 Rather than testing all of these algorithms in-place in the \CFA compiler, a resolver prototype is being developed whichacts on a simplified input language encapsulating the essential details of the \CFA type-system\footnote{Note this simplified input language is not a usable programming language.}.573 Rather than testing all of these algorithms in-place in the \CFA compiler, a resolver prototype is being developed that acts on a simplified input language encapsulating the essential details of the \CFA type-system\footnote{Note this simplified input language is not a usable programming language.}. 566 574 Multiple variants of this resolver prototype will be implemented, each encapsulating a different expression resolution variant, sharing as much code as feasible. 567 575 These variants will be instrumented to test runtime performance, and run on a variety of input files; the input files may be generated programmatically or from exisiting code in \CFA or similar languages. … … 571 579 As an example, there are currently multiple open proposals for how implicit conversions should interact with polymorphic type binding in \CFA, each with distinct levels of expressive power; if the resolver prototype is modified to support each proposal, the optimal algorithm for each proposal can be compared, providing an empirical demonstration of the trade-off between expressive power and compiler runtime. 572 580 573 This proposed project should provide valuable data on how to implement a performant compiler for modernprogramming languages such as \CFA with powerful static type-systems, specifically targeting the feature interaction between name overloading and implicit conversions.581 This proposed project should provide valuable data on how to implement a performant compiler for programming languages such as \CFA with powerful static type-systems, specifically targeting the feature interaction between name overloading and implicit conversions. 574 582 This work is not limited in applicability to \CFA, but may also be useful for supporting efficient compilation of the upcoming Concepts standard~\cite{C++concepts} for \CC template constraints, for instance. 575 583 -
doc/user/user.tex
r79841be r6943a987 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Tue Aug 2 17:39:02201614 %% Update Count : 1 28613 %% Last Modified On : Sun Aug 14 08:23:06 2016 14 %% Update Count : 1323 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 317 317 318 318 \item 319 \Indexc{-no-include-std }\index{compilation option!-no-include-std@©-no-include-std©}319 \Indexc{-no-include-stdhdr}\index{compilation option!-no-include-stdhdr@©-no-include-stdhdr©} 320 320 Do not supply ©extern "C"© wrappers for \Celeven standard include files (see~\VRef{s:StandardHeaders}). 321 321 \textbf{This option is \emph{not} the default.} … … 807 807 808 808 809 \section{Backquote Identifiers} 810 \label{s:BackquoteIdentifiers} 811 812 \CFA accommodates keyword clashes by syntactic transformations using the \CFA backquote escape-mechanism: 813 \begin{lstlisting} 814 int `otype` = 3; // make keyword an identifier 815 double `choose` = 3.5; 816 \end{lstlisting} 817 Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to an non-keyword name. 818 Clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled automatically using the preprocessor, ©#include_next© and ©-I filename©: 819 \begin{lstlisting} 820 // include file uses the CFA keyword "otype". 821 #if ! defined( otype ) // nesting ? 822 #define otype `otype` 823 #define __CFA_BFD_H__ 824 #endif // ! otype 825 826 #include_next <bfd.h> // must have internal check for multiple expansion 827 828 #if defined( otype ) && defined( __CFA_BFD_H__ ) // reset only if set 829 #undef otype 830 #undef __CFA_BFD_H__ 831 #endif // otype && __CFA_BFD_H__ 832 \end{lstlisting} 833 834 809 835 \section{Type Operators} 810 836 … … 1011 1037 Alternatively, prototype definitions can be eliminated by using a two-pass compilation, and implicitly creating header files for exports. 1012 1038 The former is easy to do, while the latter is more complex. 1013 Currently, \CFA does \emph{not} attempt to support named arguments. 1039 1040 Furthermore, named arguments do not work well in a \CFA-style programming-languages because they potentially introduces a new criteria for type matching. 1041 For example, it is technically possible to disambiguate between these two overloaded definitions of ©f© based on named arguments at the call site: 1042 \begin{lstlisting} 1043 int f( int i, int j ); 1044 int f( int x, double y ); 1045 1046 f( j : 3, i : 4 ); §\C{// 1st f}§ 1047 f( x : 7, y : 8.1 ); §\C{// 2nd f}§ 1048 f( 4, 5 ); §\C{// ambiguous call}§ 1049 \end{lstlisting} 1050 However, named arguments compound routine resolution in conjunction with conversions: 1051 \begin{lstlisting} 1052 f( i : 3, 5.7 ); §\C{// ambiguous call ?}§ 1053 \end{lstlisting} 1054 Depending on the cost associated with named arguments, this call could be resolvable or ambiguous. 1055 Adding named argument into the routine resolution algorithm does not seem worth the complexity. 1056 Therefore, \CFA does \emph{not} attempt to support named arguments. 1014 1057 1015 1058 \item[Default Arguments] … … 1021 1064 the allowable positional calls are: 1022 1065 \begin{lstlisting} 1023 p(); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§1024 p( 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§1025 p( 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§1026 p( 4, 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§1066 p(); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ 1067 p( 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§ 1068 p( 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§ 1069 p( 4, 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 4 )}§ 1027 1070 // empty arguments 1028 p( , 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§1029 p( 4, , 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§1030 p( 4, 4, ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§1031 p( 4, , ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§1032 p( , 4, ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§1033 p( , , 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§1034 p( , , ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§1071 p( , 4, 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 4 )}§ 1072 p( 4, , 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 4 )}§ 1073 p( 4, 4, ); §\C{// rewrite $\Rightarrow$ p( 4, 4, 3 )}§ 1074 p( 4, , ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§ 1075 p( , 4, ); §\C{// rewrite $\Rightarrow$ p( 1, 4, 3 )}§ 1076 p( , , 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§ 1077 p( , , ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ 1035 1078 \end{lstlisting} 1036 1079 Here the missing arguments are inserted from the default values in the parameter list. … … 1067 1110 The conflict occurs because both named and ellipse arguments must appear after positional arguments, giving two possibilities: 1068 1111 \begin{lstlisting} 1069 p( /* positional */, . . ., /* named */ );1070 p( /* positional */, /* named */, . .. );1112 p( /* positional */, ... , /* named */ ); 1113 p( /* positional */, /* named */, ... ); 1071 1114 \end{lstlisting} 1072 1115 While it is possible to implement both approaches, the first possibly is more complex than the second, \eg: 1073 1116 \begin{lstlisting} 1074 p( int x, int y, int z, . .. );1075 p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, . . ., /* named */ );}§1076 p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, . .. );}§1117 p( int x, int y, int z, ... ); 1118 p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, ... , /* named */ );}§ 1119 p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§ 1077 1120 \end{lstlisting} 1078 1121 In the first call, it is necessary for the programmer to conceptually rewrite the call, changing named arguments into positional, before knowing where the ellipse arguments begin. … … 1082 1125 The problem is exacerbated with default arguments, \eg: 1083 1126 \begin{lstlisting} 1084 void p( int x, int y = 2, int z = 3. .. );1085 p( 1, 4, 5, 6, z : 3 ); §\C{// assume p( /* positional */, . . ., /* named */ );}§1086 p( 1, z : 3, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, . .. );}§1127 void p( int x, int y = 2, int z = 3... ); 1128 p( 1, 4, 5, 6, z : 3 ); §\C{// assume p( /* positional */, ... , /* named */ );}§ 1129 p( 1, z : 3, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§ 1087 1130 \end{lstlisting} 1088 1131 The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments; … … 1129 1172 \subsection{Type Nesting} 1130 1173 1131 \CFA allows \Index{type nesting}, and type qualification of the nested typ es (see \VRef[Figure]{f:TypeNestingQualification}), where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification.1174 \CFA allows \Index{type nesting}, and type qualification of the nested typres (see \VRef[Figure]{f:TypeNestingQualification}), where as C hoists\index{type hoisting} (refactors) nested types into the enclosing scope and has no type qualification. 1132 1175 \begin{figure} 1176 \centering 1133 1177 \begin{tabular}{@{}l@{\hspace{3em}}l|l@{}} 1134 1178 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}} & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}} & \multicolumn{1}{|c}{\textbf{\CFA}} \\ … … 1397 1441 Mass assignment has the following form: 1398 1442 \begin{lstlisting} 1399 [ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§;1443 [ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§; 1400 1444 \end{lstlisting} 1401 1445 \index{lvalue} … … 1437 1481 Multiple assignment has the following form: 1438 1482 \begin{lstlisting} 1439 [ §\emph{lvalue}§, . . ., §\emph{lvalue}§ ] = [ §\emph{expr}§, . . ., §\emph{expr}§ ];1483 [ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ]; 1440 1484 \end{lstlisting} 1441 1485 \index{lvalue} … … 1873 1917 \begin{lstlisting} 1874 1918 switch ( i ) { 1875 ®case1, 3, 5®:1919 case ®1, 3, 5®: 1876 1920 ... 1877 ®case2, 4, 6®:1921 case ®2, 4, 6®: 1878 1922 ... 1879 1923 } … … 1906 1950 \begin{lstlisting} 1907 1951 switch ( i ) { 1908 ®case1~5:®1952 case ®1~5:® 1909 1953 ... 1910 ®case10~15:®1954 case ®10~15:® 1911 1955 ... 1912 1956 } … … 1915 1959 \begin{lstlisting} 1916 1960 switch ( i ) 1917 case 1 ... 5:1961 case ®1 ... 5®: 1918 1962 ... 1919 case 10 ... 15:1963 case ®10 ... 15®: 1920 1964 ... 1921 1965 } … … 4369 4413 4370 4414 4415 \section{Incompatible} 4416 4417 The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{ANSI14:C++}. 4418 4419 \begin{enumerate} 4420 \item 4421 \begin{description} 4422 \item[Change:] add new keywords \\ 4423 New keywords are added to \CFA (see~\VRef{s:NewKeywords}). 4424 \item[Rationale:] keywords added to implement new semantics of \CFA. 4425 \item[Effect on original feature:] change to semantics of well-defined feature. \\ 4426 Any ISO C programs using these keywords as identifiers are invalid \CFA programs. 4427 \item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism (see~\VRef{s:BackquoteIdentifiers}): 4428 \item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare. 4429 \end{description} 4430 4431 \item 4432 \begin{description} 4433 \item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading: 4434 \begin{lstlisting} 4435 int rtn( int i ); 4436 int rtn( char c ); 4437 rtn( 'x' ); §\C{// programmer expects 2nd rtn to be called}§ 4438 \end{lstlisting} 4439 \item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first. 4440 In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character. 4441 \begin{lstlisting} 4442 sout | 'x' | " " | (int)'x' | endl; 4443 x 120 4444 \end{lstlisting} 4445 Having to cast ©'x'© to ©char© is non-intuitive. 4446 \item[Effect on original feature:] change to semantics of well-defined feature that depend on: 4447 \begin{lstlisting} 4448 sizeof( 'x' ) == sizeof( int ) 4449 \end{lstlisting} 4450 no long work the same in \CFA programs. 4451 \item[Difficulty of converting:] simple 4452 \item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©. 4453 \end{description} 4454 4455 \item 4456 \begin{description} 4457 \item[Change:] make string literals ©const©: 4458 \begin{lstlisting} 4459 char * p = "abc"; §\C{// valid in C, deprecated in \CFA}§ 4460 char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§ 4461 \end{lstlisting} 4462 The type of a string literal is changed from ©[] char© to ©const [] char©. 4463 Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©. 4464 \item[Rationale:] This change is a safety issue: 4465 \begin{lstlisting} 4466 char * p = "abc"; 4467 p[0] = 'w'; §\C{// segment fault or change constant literal}§ 4468 \end{lstlisting} 4469 The same problem occurs when passing a string literal to a routine that changes its argument. 4470 \item[Effect on original feature:] change to semantics of well-defined feature. 4471 \item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©. 4472 \item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare. 4473 \end{description} 4474 4475 \item 4476 \begin{description} 4477 \item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope: 4478 \begin{lstlisting} 4479 int i; §\C{// forward definition}§ 4480 int *j = ®&i®; §\C{// forward reference, valid in C, invalid in \CFA}§ 4481 int i = 0; §\C{// definition}§ 4482 \end{lstlisting} 4483 is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed. 4484 This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example, 4485 \begin{lstlisting} 4486 struct X { int i; struct X *next; }; 4487 static struct X a; §\C{// forward definition}§ 4488 static struct X b = { 0, ®&a® }; §\C{// forward reference, valid in C, invalid in \CFA}§ 4489 static struct X a = { 1, &b }; §\C{// definition}§ 4490 \end{lstlisting} 4491 \item[Rationale:] avoids having different initialization rules for builtin types and userdefined types. 4492 \item[Effect on original feature:] change to semantics of well-defined feature. 4493 \item[Difficulty of converting:] the initializer for one of a set of mutually-referential file-local static objects must invoke a routine call to achieve the initialization. 4494 \item[How widely used:] seldom 4495 \end{description} 4496 4497 \item 4498 \begin{description} 4499 \item[Change:] have ©struct© introduce a scope for nested types: 4500 \begin{lstlisting} 4501 enum ®Colour® { R, G, B, Y, C, M }; 4502 struct Person { 4503 enum ®Colour® { R, G, B }; §\C{// nested type}§ 4504 struct Face { §\C{// nested type}§ 4505 ®Colour® Eyes, Hair; §\C{// type defined outside (1 level)}§ 4506 }; 4507 ß.ß®Colour® shirt; §\C{// type defined outside (top level)}§ 4508 ®Colour® pants; §\C{// type defined same level}§ 4509 Face looks[10]; §\C{// type defined same level}§ 4510 }; 4511 ®Colour® c = R; §\C{// type/enum defined same level}§ 4512 Personß.ß®Colour® pc = Personß.ßR; §\C{// type/enum defined inside}§ 4513 Personß.ßFace pretty; §\C{// type defined inside}§ 4514 \end{lstlisting} 4515 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, i.e., the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing. 4516 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}. 4517 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''. 4518 \item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism. 4519 \item[Effect on original feature:] change to semantics of well-defined feature. 4520 \item[Difficulty of converting:] Semantic transformation. 4521 \item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version. 4522 \end{description} 4523 4524 \item 4525 \begin{description} 4526 \item[Change:] In C++, the name of a nested class is local to its enclosing class. 4527 \item[Rationale:] C++ classes have member functions which require that classes establish scopes. 4528 \item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example: 4529 \begin{lstlisting} 4530 struct Y; §\C{// struct Y and struct X are at the same scope}§ 4531 struct X { 4532 struct Y { /* ... */ } y; 4533 }; 4534 \end{lstlisting} 4535 All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct. 4536 Note: this is a consequence of the difference in scope rules, which is documented in 3.3. 4537 \item[How widely used:] Seldom. 4538 \end{description} 4539 4540 \item 4541 \begin{description} 4542 \item[Change:] comma expression is disallowed as subscript 4543 \item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new style arrays. 4544 \item[Effect on original feature:] change to semantics of well-defined feature. 4545 \item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]© 4546 \item[How widely used:] seldom. 4547 \end{description} 4548 \end{enumerate} 4549 4550 4371 4551 \section{New Keywords} 4372 4552 \label{s:NewKeywords} 4373 4553 4374 4554 \begin{quote2} 4375 \begin{tabular}{ll} 4376 ©catch© & ©lvalue© \\ 4377 ©catchResume© & \\ 4378 ©choose© & ©otype© \\ 4379 & \\ 4380 ©disable© & ©throw© \\ 4381 ©dtype© & ©throwResume© \\ 4382 & ©trait© \\ 4383 ©enable© & ©try© \\ 4384 & \\ 4385 ©fallthrough© \\ 4386 ©fallthru© \\ 4387 ©finally© \\ 4388 ©forall© \\ 4389 ©ftype© \\ 4555 \begin{tabular}{lll} 4556 ©catch© & ©fallthrough© & ©otype© \\ 4557 ©catchResume© & ©fallthru© & ©throw© \\ 4558 ©choose© & ©finally© & ©throwResume© \\ 4559 ©disable© & ©forall© & ©trait© \\ 4560 ©dtype© & ©ftype© & ©try© \\ 4561 ©enable© & ©lvalue© & \\ 4390 4562 \end{tabular} 4391 4563 \end{quote2} … … 4395 4567 \label{s:StandardHeaders} 4396 4568 4397 C prescribes the following standard header-files :4569 C prescribes the following standard header-files~\cite[\S~7.1.2]{C11}: 4398 4570 \begin{quote2} 4399 4571 \begin{minipage}{\linewidth} … … 4412 4584 \end{minipage} 4413 4585 \end{quote2} 4414 For the prescribed head-files, \CFA implicit wraps their includes in an ©extern "C"©;4586 For the prescribed head-files, \CFA implicitly wraps their includes in an ©extern "C"©; 4415 4587 hence, names in these include files are not mangled\index{mangling!name} (see~\VRef{s:Interoperability}). 4416 4588 All other C header files must be explicitly wrapped in ©extern "C"© to prevent name mangling. 4417 4418 4419 \section{Incompatible}4420 4421 The following incompatibles exist between \CFA and C, and are similar to Annex C for \CC~\cite{ANSI14:C++}.4422 4423 \begin{enumerate}4424 \item4425 \begin{description}4426 \item[Change:] add new keywords (see~\VRef{s:NewKeywords}) \\4427 New keywords are added to \CFA.4428 \item[Rationale:] keywords added to implement new semantics of \CFA.4429 \item[Effect on original feature:] change to semantics of well-defined feature. \\4430 Any ISO C programs using these keywords as identifiers are invalid \CFA programs.4431 \item[Difficulty of converting:] keyword clashes are accommodated by syntactic transformations using the \CFA backquote escape-mechanism:4432 \begin{lstlisting}4433 int `otype` = 3; // make keyword an identifier4434 double `choose` = 3.5;4435 \end{lstlisting}4436 Programs can be converted automatically by enclosing keyword identifiers in backquotes, and the backquotes can be remove later when the identifier name is changed.4437 Clashes in C system libraries (include files) can be handled automatically using preprocessor, ©#include_next© and ©-Ifilename©:4438 \begin{lstlisting}4439 // include file uses the CFA keyword "otype".4440 #if ! defined( otype ) // nesting ?4441 #define otype `otype`4442 #define __CFA_BFD_H__4443 #endif // ! otype4444 4445 #include_next <bfd.h> // must have internal check for multiple expansion4446 4447 #if defined( otype ) && defined( __CFA_BFD_H__ ) // reset only if set4448 #undef otype4449 #undef __CFA_BFD_H__4450 #endif // otype && __CFA_BFD_H__4451 \end{lstlisting}4452 \item[How widely used:] clashes among new \CFA keywords and existing identifiers are rare.4453 \end{description}4454 4455 \item4456 \begin{description}4457 \item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading:4458 \begin{lstlisting}4459 int rtn( int i );4460 int rtn( char c );4461 rtn( 'x' ); // programmer expects 2nd rtn to be called4462 \end{lstlisting}4463 \item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first.4464 In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character.4465 \begin{lstlisting}4466 sout | 'x' | " " | (int)'x' | endl;4467 x 1204468 \end{lstlisting}4469 Having to cast ©'x'© to ©char© is non-intuitive.4470 \item[Effect on original feature:] change to semantics of well-defined feature that depend on:4471 \begin{lstlisting}4472 sizeof( 'x' ) == sizeof( int )4473 \end{lstlisting}4474 no long work the same in \CFA programs.4475 \item[Difficulty of converting:] simple4476 \item[How widely used:] programs that depend upon ©sizeof( 'x' )© are rare and can be changed to ©sizeof(char)©.4477 \end{description}4478 4479 \item4480 \begin{description}4481 \item[Change:] make string literals ©const©:4482 \begin{lstlisting}4483 char * p = "abc"; // valid in C, deprecated in §\CFA§4484 char * q = expr ? "abc" : "de"; // valid in C, invalid in §\CFA§4485 \end{lstlisting}4486 The type of a string literal is changed from ©[] char© to ©const [] char©.4487 Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©.4488 \item[Rationale:] This change is a safety issue:4489 \begin{lstlisting}4490 char * p = "abc";4491 p[0] = 'w'; // segment fault or change constant literal4492 \end{lstlisting}4493 The same problem occurs when passing a string literal to a routine that changes its argument.4494 \item[Effect on original feature:] change to semantics of well-defined feature.4495 \item[Difficulty of converting:] simple syntactic transformation, because string literals can be converted to ©char *©.4496 \item[How widely used:] programs that have a legitimate reason to treat string literals as pointers to potentially modifiable memory are rare.4497 \end{description}4498 4499 \item4500 \begin{description}4501 \item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope:4502 \begin{lstlisting}4503 int i; // forward definition4504 int *j = ®&i®; // forward reference, valid in C, invalid in §\CFA§4505 int i = 0; // definition4506 \end{lstlisting}4507 is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed.4508 This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example,4509 \begin{lstlisting}4510 struct X { int i; struct X *next; };4511 static struct X a; // forward definition4512 static struct X b = { 0, ®&a® }; // forward reference, valid in C, invalid in §\CFA§4513 static struct X a = { 1, &b }; // definition4514 \end{lstlisting}4515 \item[Rationale:] avoids having different initialization rules for builtin types and userdefined types.4516 \item[Effect on original feature:] change to semantics of well-defined feature.4517 \item[Difficulty of converting:] the initializer for one of a set of mutually-referential file-local static objects must invoke a routine call to achieve the initialization.4518 \item[How widely used:] seldom4519 \end{description}4520 4521 \item4522 \begin{description}4523 \item[Change:] have ©struct© introduce a scope for nested types4524 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing4525 Example:4526 \begin{lstlisting}4527 enum ®Colour® { R, G, B, Y, C, M };4528 struct Person {4529 enum ®Colour® { R, G, B }; // nested type4530 struct Face { // nested type4531 ®Colour® Eyes, Hair; // type defined outside (1 level)4532 };4533 ß.ß®Colour® shirt; // type defined outside (top level)4534 ®Colour® pants; // type defined same level4535 Face looks[10]; // type defined same level4536 };4537 ®Colour® c = R; // type/enum defined same level4538 Personß.ß®Colour® pc = Personß.ßR; // type/enum defined inside4539 Personß.ßFace pretty; // type defined inside4540 \end{lstlisting}4541 \item[Rationale:] ©struct© scope is crucial to \CFA as an information structuring and hiding mechanism.4542 \item[Effect on original feature:] change to semantics of well-defined feature.4543 \item[Difficulty of converting:] Semantic transformation.4544 \item[How widely used:] C programs rarely have nest types because they are equivalent to the hoisted version.4545 4546 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}.4547 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''.4548 Given that nested types in C are equivalent to not using them, \ie they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.4549 \end{description}4550 4551 \item4552 \begin{description}4553 \item[Change:] In C++, the name of a nested class is local to its enclosing class.4554 \item[Rationale:] C++ classes have member functions which require that classes establish scopes.4555 \item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example:4556 \begin{lstlisting}4557 struct Y; // struct Y and struct X are at the same scope4558 struct X {4559 struct Y { /* ... */ } y;4560 };4561 \end{lstlisting}4562 All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct.4563 Note: this is a consequence of the difference in scope rules, which is documented in 3.3.4564 \item[How widely used:] Seldom.4565 \end{description}4566 4567 \item4568 \begin{description}4569 \item[Change:] comma expression is disallowed as subscript4570 \item[Rationale:] safety issue to prevent subscripting error for multidimensional arrays: ©x[i,j]© instead of ©x[i][j]©, and this syntactic form then taken by \CFA for new style arrays.4571 \item[Effect on original feature:] change to semantics of well-defined feature.4572 \item[Difficulty of converting:] semantic transformation of ©x[i,j]© to ©x[(i,j)]©4573 \item[How widely used:] seldom.4574 \end{description}4575 \end{enumerate}4576 4589 4577 4590 … … 4749 4762 \subsection{malloc} 4750 4763 4764 \leavevmode 4751 4765 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4752 4766 forall( otype T ) T * malloc( void );§\indexc{malloc}§ … … 4765 4779 forall( otype T ) T * memset( T * ptr ); // remove when default value available 4766 4780 \end{lstlisting} 4767 \ 4781 4768 4782 4769 4783 \subsection{ato / strto} 4770 4784 4785 \leavevmode 4771 4786 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4772 4787 int ato( const char * ptr );§\indexc{ato}§ … … 4796 4811 long double _Complex strto( const char * sptr, char ** eptr ); 4797 4812 \end{lstlisting} 4798 \4799 4813 4800 4814 4801 4815 \subsection{bsearch / qsort} 4802 4816 4817 \leavevmode 4803 4818 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4804 4819 forall( otype T | { int ?<?( T, T ); } ) … … 4808 4823 void qsort( const T * arr, size_t dimension );§\indexc{qsort}§ 4809 4824 \end{lstlisting} 4810 \4811 4825 4812 4826 4813 4827 \subsection{abs} 4814 4828 4829 \leavevmode 4815 4830 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4816 4831 char abs( char );§\indexc{abs}§ … … 4825 4840 long double abs( long double _Complex ); 4826 4841 \end{lstlisting} 4827 \4828 4842 4829 4843 4830 4844 \subsection{random} 4831 4845 4846 \leavevmode 4832 4847 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4833 4848 void rand48seed( long int s );§\indexc{rand48seed}§ … … 4843 4858 long double _Complex rand48(); 4844 4859 \end{lstlisting} 4845 \4846 4860 4847 4861 4848 4862 \subsection{min / max / clamp / swap} 4849 4863 4864 \leavevmode 4850 4865 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4851 4866 forall( otype T | { int ?<?( T, T ); } ) … … 4861 4876 void swap( T * t1, T * t2 );§\indexc{swap}§ 4862 4877 \end{lstlisting} 4863 \4864 4878 4865 4879 … … 4872 4886 \subsection{General} 4873 4887 4888 \leavevmode 4874 4889 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4875 4890 float fabs( float );§\indexc{fabs}§ … … 4917 4932 long double nan( const char * ); 4918 4933 \end{lstlisting} 4919 \4920 4934 4921 4935 4922 4936 \subsection{Exponential} 4923 4937 4938 \leavevmode 4924 4939 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4925 4940 float exp( float );§\indexc{exp}§ … … 4974 4989 long double logb( long double ); 4975 4990 \end{lstlisting} 4976 \4977 4991 4978 4992 4979 4993 \subsection{Power} 4980 4994 4995 \leavevmode 4981 4996 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 4982 4997 float sqrt( float );§\indexc{sqrt}§ … … 5002 5017 long double _Complex pow( long double _Complex, long double _Complex ); 5003 5018 \end{lstlisting} 5004 \5005 5019 5006 5020 5007 5021 \subsection{Trigonometric} 5008 5022 5023 \leavevmode 5009 5024 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5010 5025 float sin( float );§\indexc{sin}§ … … 5058 5073 long double atan( long double, long double ); 5059 5074 \end{lstlisting} 5060 \5061 5075 5062 5076 5063 5077 \subsection{Hyperbolic} 5064 5078 5079 \leavevmode 5065 5080 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5066 5081 float sinh( float );§\indexc{sinh}§ … … 5106 5121 long double _Complex atanh( long double _Complex ); 5107 5122 \end{lstlisting} 5108 \5109 5123 5110 5124 5111 5125 \subsection{Error / Gamma} 5112 5126 5127 \leavevmode 5113 5128 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5114 5129 float erf( float );§\indexc{erf}§ … … 5137 5152 long double tgamma( long double ); 5138 5153 \end{lstlisting} 5139 \5140 5154 5141 5155 5142 5156 \subsection{Nearest Integer} 5143 5157 5158 \leavevmode 5144 5159 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5145 5160 float floor( float );§\indexc{floor}§ … … 5191 5206 long long int llround( long double ); 5192 5207 \end{lstlisting} 5193 \5194 5208 5195 5209 5196 5210 \subsection{Manipulation} 5197 5211 5212 \leavevmode 5198 5213 \begin{lstlisting}[aboveskip=0pt,belowskip=0pt] 5199 5214 float copysign( float, float );§\indexc{copysign}§ … … 5232 5247 long double scalbln( long double, long int ); 5233 5248 \end{lstlisting} 5234 \5235 5249 5236 5250
Note:
See TracChangeset
for help on using the changeset viewer.