Context Navigation

-                      rc87eb50
+                      r0111dc7
 \chapter{Conclusions}
 %======================================================================
+Adding resource management and tuples to \CFA has been a challenging design, engineering, and implementation exercise.
+On the surface, the work may appear as a rehash of similar mechanisms in \CC.
+However, every added feature is different than its \CC counterpart, often with extended functionality, better integration with C and its programmers, and always supports separate compilation.
+All of these new features are being used by the \CFA development-team to build the \CFA runtime system.
 \section{Constructors and Destructors}
 …
 \section{Variadic Functions}
 Type-safe variadic functions of a similar feel to variadic templates are added to \CFA.
+Type-safe variadic functions, with a similar feel to variadic templates, are added to \CFA.
 The new variadic functions can express complicated recursive algorithms.
 Unlike variadic templates, it is possible to write @new@ as a library routine and to separately compile @ttype@ polymorphic functions.
 …
 The design space is currently being explored with the goal of finding an alternative to move semantics that provides necessary performance benefits, while reducing the amount of repetition required to create a new type, along with the cognitive burden placed on the user.
+% One technique being evaluated is whether named return-values can be used to eliminate unnecessary temporaries \cite{Buhr94a}.
+% For example,
+% \begin{cfacode}
+% struct A { ... };
+% [A x] f(A x);
+% [A y] g(A y);
+% [A z] h(A z);
+% struct A a1, a2;
+% a2 = h(g(f(a1)));
+% \end{cfacode}
+% Here, since both @f@'s argument and return value have the same name and type, the compiler can infer that @f@ returns its argument.
+% With this knowledge, the compiler can reuse the storage for the argument to @f@ as the argument to @g@.  % TODO: cite Till thesis?
 Exception handling is among the features expected to be added to \CFA in the near future.
 For exception handling to properly interact with the rest of the language, it must ensure all RAII guarantees continue to be met.
 …
 This mechanism is known and understood by GCC, so that the destructor is properly called in any situation where a variable goes out of scope, including function returns, branches, and built-in GCC exception handling mechanisms using libunwind.
 A caveat of this approach is that the @cleanup@ attribute only permits a name that refers to a function that consumes a single argument of type @T *@ for a variable of type @T@.
 This means that any destructor that consumes multiple arguments (\eg, because it is polymorphic) or any destructor that is a function pointer (\eg, because it is an assertion parameter) must be called through a local thunk.
+A caveat of this approach is that the @cleanup@ attribute only permits a function that consumes a single argument of type @T *@ for a variable of type @T@.
+This restriction means that any destructor that consumes multiple arguments (\eg, because it is polymorphic) or any destructor that is a function pointer (\eg, because it is an assertion parameter) must be called through a local thunk.
 For example,
 \begin{cfacode}
 …
   T x;
 };
 forall(otype T) void ^?{}(Box(T) * x);
+forall(otype T) void ^?{}(Box(T) * x); // has implicit parameters
 forall(otype T)
 void f(T x) {
   T y = x;
   Box(T) z = { x };
+  T y = x;  // destructor is a function-pointer parameter
+  Box(T) z = { x }; // destructor has multiple parameters
+}
 \end{cfacode}
 …
 void _dtor_S(struct S *);
 struct __tmp_bundle_S {
+struct _tmp_bundle_S {
   bool valid;
   struct S value;
 };
 void _dtor_tmpS(struct __tmp_bundle_S * ret) {
+void _dtor_tmpS(struct _tmp_bundle_S * ret) {
   if (ret->valid) {
     _dtor_S(&ret->value);
 …
+{
   __attribute__((cleanup(_dtor_tmpS))) struct __tmp_bundle_S _tmp1 = { 0 };
   __attribute__((cleanup(_dtor_tmpS))) struct __tmp_bundle_S _tmp2 = { 0 };
   __attribute__((cleanup(_dtor_tmpS))) struct __tmp_bundle_S _tmp3 = { 0 };
+  __attribute__((cleanup(_dtor_tmpS))) struct _tmp_bundle_S _tmp1 = { 0 };
+  __attribute__((cleanup(_dtor_tmpS))) struct _tmp_bundle_S _tmp2 = { 0 };
+  __attribute__((cleanup(_dtor_tmpS))) struct _tmp_bundle_S _tmp3 = { 0 };
   _tmp2.value = g(
     (_ctor_S(
 …
 struct S { T x; };
 \end{cfacode}
 will only auto-generate the default constructor for @S@, since the member @x@ is missing the other 3 special functions.
+only auto-generates the default constructor for @S@, since the member @x@ is missing the other 3 special functions.
 Once deleted functions have been added, function generation can make use of this information to disable generation of special functions when a member has a deleted function.
 For example,
 …
 struct B { ... };
 struct A {
         B x, y, z;
+  B x, y, z;
 };
 void ?{}(A * a, B x) {
         // y, z implicitly default constructed
         (&a->x){ ... }; // explicitly construct x
+  // y, z implicitly default constructed
+  (&a->x){ ... }; // explicitly construct x
 } // constructs an entire A
 void ?{}(A * a) {
         (&a->y){}; // initialize y
         a{ (B){ ... } }; // forwarding constructor call
                          // initializes entire object, including y
+  (&a->y){}; // initialize y
+  a{ (B){ ... } }; // forwarding constructor call
+                   // initializes entire object, including y
+}
 \end{cfacode}
 Finally, while constructors provide a mechanism for establishing invariants, there is currently no mechanism for maintaining invariants without resorting to opaque types.
 That is, structure fields can be accessed and modified by any block of code without restriction, so while it's possible to ensure that an object is initially set to a valid state, it isn't possible to ensure that it remains in a consistent state throughout its lifetime.
+That is, structure fields can be accessed and modified by any block of code without restriction, so while it is possible to ensure that an object is initially set to a valid state, it is not possible to ensure that it remains in a consistent state throughout its lifetime.
 A popular technique for ensuring consistency in object-oriented programming languages is to provide access modifiers such as @private@, which provides compile-time checks that only privileged code accesses private data.
 This approach could be added to \CFA, but it requires an idiomatic way of specifying what code is privileged.
 …
 \subsection{Variadic Functions}
 Use of @ttype@ functions currently relies heavily on recursion.
 \CC has opened variadic templates up so that recursion isn't strictly necessary in some cases, and it would be interesting to see if any such cases can be applied to \CFA.
 \CC supports variadic templated data types, making it possible to express arbitrary length tuples, arbitrary parameter function objects, and more with generic types.
 Currently, \CFA does not support @ttype@-parameter generic types, though there does not appear to be a technical reason that it cannot.
+\CC has opened variadic templates up so that recursion is not strictly necessary in some cases, and it would be interesting to see if any such cases can be applied to \CFA.
+\CC supports variadic templated data-types, making it possible to express arbitrary length tuples, arbitrary parameter function objects, and more with generic types.
+Currently, \CFA does not support @ttype@-parameter generic-types, though there does not appear to be a technical reason that it cannot.
 Notably, opening up support for this makes it possible to implement the exit form of scope guard (see section \ref{s:ResMgmt}), making it possible to call arbitrary functions at scope exit in idiomatic \CFA.

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

Context Navigation

Changeset 0111dc7 for doc/rob_thesis/conclusions.tex

Legend:

doc/rob_thesis/conclusions.tex

Download in other formats: