Changeset a95310e3 for doc/generic_types/generic_types.tex
- Timestamp:
- Apr 5, 2017, 10:38:55 AM (8 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, 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:
- 7a026ff
- Parents:
- 8f5bf6d
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/generic_types/generic_types.tex
r8f5bf6d ra95310e3 149 149 Nonetheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive. 150 150 151 \CFA (pronounced ``C-for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that aims to add modern language features to C while maintaining both source compatibility with C and a familiar programming model for programmers. Four key design goals were set out in the original design of \CFA~\citep{Bilson03}:151 \CFA (pronounced ``C-for-all'', and written \CFA or Cforall) is an evolutionary extension of the C programming language that aims to add modern language features to C while maintaining both source compatibility with C and a familiar programming model for programmers. The four key design goals for \CFA~\citep{Bilson03} are: 152 152 (1) The behaviour of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler; 153 153 (2) Standard C code must be as fast and as small when translated by a \CFA compiler as when translated by a C compiler; 154 154 (3) \CFA code must be at least as portable as standard C code; 155 155 (4) Extensions introduced by \CFA must be translated in the most efficient way possible. 156 These goals ensure existing C code-bases can be converted to \CFA incrementally and with minimal effort, and C programmers can productively generate \CFA code without training beyond the features they wish to employ. In its current implementation, \CFA is compiled by translating it to the GCC-dialect of C~\citep{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by GCC, meeting goals (1)-(3). Ultimately, a compiler is necessary for advanced features and optimal performance.157 158 \CFA has been previously extended with polymorphic functions and name overloading (including operator overloading) by \citet{Bilson03}, and deterministically-executed constructors and destructors by \citet{Schluntz17}. This paper builds on those contributions, identifying shortcomings in existing approaches to generic and variadic data types in C-like languages and presentinga design for generic and variadic types avoiding those shortcomings. Specifically, the solution is both reusable and type-checked, as well as conforming to the design goals of \CFA with ergonomic use of existing C abstractions. The new constructs are empirically compared with both standard C and \CC; the results show the new design is comparable in performance.156 These goals ensure existing C code-bases can be converted to \CFA incrementally with minimal effort, and C programmers can productively generate \CFA code without training beyond the features being used. In its current implementation, \CFA is compiled by translating it to the GCC-dialect of C~\citep{GCCExtensions}, allowing it to leverage the portability and code optimizations provided by GCC, meeting goals (1)-(3). Ultimately, a compiler is necessary for advanced features and optimal performance. 157 158 This paper identifies shortcomings in existing approaches to generic and variadic data types in C-like languages and presents a design for generic and variadic types avoiding those shortcomings. Specifically, the solution is both reusable and type-checked, as well as conforming to the design goals of \CFA with ergonomic use of existing C abstractions. The new constructs are empirically compared with both standard C and \CC; the results show the new design is comparable in performance. 159 159 160 160 … … 224 224 Call-site inferencing and nested functions provide a localized form of inheritance. For example, @qsort@ only sorts in ascending order using @<@. However, it is trivial to locally change this behaviour: 225 225 \begin{lstlisting} 226 { int ?<?( double x, double y ) { return x `>` y; } $\C{// override behaviour}$ 226 { 227 int ?<?( double x, double y ) { return x `>` y; } $\C{// override behaviour}$ 227 228 qsort( vals, size ); $\C{// descending sort}$ 228 229 } … … 257 258 \begin{lstlisting} 258 259 trait summable( otype T ) { 259 void ?{}( T*, zero_t);$\C{// constructor from 0 literal}$260 void ?{}( T *, zero_t ); $\C{// constructor from 0 literal}$ 260 261 T ?+?( T, T ); $\C{// assortment of additions}$ 261 262 T ?+=?( T *, T ); … … 263 264 T ?++( T * ); 264 265 }; 265 forall( otype T | summable( T ) ) 266 T sum( T a[$\,$], size_t size ) { 267 `T` total = { `0` }; $\C{// instantiate T from 0 but calling its constructor}$ 266 forall( otype T `| summable( T )` ) T sum( T a[$\,$], size_t size ) { // use trait 267 `T` total = { `0` }; $\C{// instantiate T from 0 by calling its constructor}$ 268 268 for ( unsigned int i = 0; i < size; i += 1 ) 269 269 total `+=` a[i]; $\C{// select appropriate +}$
Note: See TracChangeset
for help on using the changeset viewer.