# Changeset 7a026ff

Ignore:
Timestamp:
Apr 5, 2017, 12:18:01 PM (6 years ago)
Branches:
aaron-thesis, arm-eh, 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:
2f0a3599, 75ac87e
Parents:
22444f4 (diff), a95310e3 (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.
Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

File:
1 edited

### Legend:

Unmodified
 r22444f4 Nonetheless, C, first standardized over thirty years ago, lacks many features that make programming in more modern languages safer and more productive. \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}: \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: (1) The behaviour of standard C code must remain the same when translated by a \CFA compiler as when translated by a C compiler; (2) Standard C code must be as fast and as small when translated by a \CFA compiler as when translated by a C compiler; (3) \CFA code must be at least as portable as standard C code; (4) Extensions introduced by \CFA must be translated in the most efficient way possible. 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. \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 presenting 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. 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. 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. 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: \begin{lstlisting} {   int ? y; }   $\C{// override behaviour}$ { int ? y; }       $\C{// override behaviour}$ qsort( vals, size );                                    $\C{// descending sort}$ } \begin{lstlisting} trait summable( otype T ) { void ?{}(T*, zero_t);                                   $\C{// constructor from 0 literal}$ void ?{}( T *, zero_t );                                $\C{// constructor from 0 literal}$ T ?+?( T, T );                                                  $\C{// assortment of additions}$ T ?+=?( T *, T ); T ?++( T * ); }; forall( otype T | summable( T ) ) T sum( T a[$\,$], size_t size ) { T total = { 0 };                                    $\C{// instantiate T from 0 but calling its constructor}$ forall( otype T | summable( T ) ) T sum( T a[$\,$], size_t size ) {  // use trait T total = { 0 };                                    $\C{// instantiate T from 0 by calling its constructor}$ for ( unsigned int i = 0; i < size; i += 1 ) total += a[i];                                        $\C{// select appropriate +}$