Context Navigation

-                      rc51b5a3
+                      rf92aa32
 %======================================================================
 % TODO: as an experiment, implement Andrei Alexandrescu's ScopeGuard http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758?pgno=2
+% TODO now: as an experiment, implement Andrei Alexandrescu's ScopeGuard http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758?pgno=2
 % doesn't seem possible to do this without allowing ttype on generic structs?
-% If a Cforall constructor is in scope, C style initialization is
-% disabled by default.
-% * initialization rule: if any constructor is in scope for type T, try
-%   to find a matching constructor for the call. If there are no
-%   constructors in scope for type T, then attempt to fall back on
-%   C-style initialization.
-% + if this rule was not in place, it would be easy to accidentally
-%   use C-style initialization in certain cases, which could lead to
-%   subtle errors [2]
-% - this means we need special syntax if we want to allow users to force
-%   a C-style initialization (to give users more control)
-% - two different declarations in the same scope can be implicitly
-%   initialized differently. That is, there may be two objects of type
-%   T that are initialized differently because there is a constructor
-%   definition between them. This is not technically specific to
-%   constructors.
-% C-style initializers can be accessed with @= syntax
-% + provides a way to get around the requirement of using a constructor
-%   (for advanced programmers only)
-% - can break invariants in the type => unsafe
-% * provides a way of asserting that a variable is an instance of a
-%   C struct (i.e. a POD struct), and so will not be implicitly
-%   destructed (this can be useful at times, maybe mitigates the need
-%   for move semantics?) [3]
-% + can modernize a code base one step at a time
-% Cforall constructors can be used in expressions to initialize any
-% piece of memory.
-% + malloc() { ... } calls the appropriate constructor on the newly
-%   allocated space; the argument is moved into the constructor call
-%   without taking its address [4]
-% - with the above form, there is still no way to ensure that
-%   dynamically allocated objects are constructed. To resolve this,
-%   we might want a stronger "new" function which always calls the
-%   constructor, although how we accomplish that is currently still
-%   unresolved (compiler magic vs. better variadic functions?)
-% + This can be used as a placement syntax [5]
-% - can call the constructor on an object more than once, which could
-%   cause resource leaks and reinitialize const fields (can try to
-%   detect and prevent this in some cases)
-%   * compiler always tries to implicitly insert a ctor/dtor pair for
-%     non-@= objects.
-%     * For POD objects, this will resolve to an autogenerated or
-%       intrinsic function.
-%     * Intrinsic functions are not automatically called. Autogenerated
-%       are, because they may call a non-autogenerated function.
-%     * destructors are automatically inserted at appropriate branches
-%       (e.g. return, break, continue, goto) and at the end of the block
-%       in which they are declared.
-%   * For @= objects, the compiler never tries to interfere and insert
-%     constructor and destructor calls for that object. Copy constructor
-%     calls do not count, because the object is not the target of the copy
-%     constructor.
-% A constructor is declared with the name ?{}
-% + combines the look of C initializers with the precedent of ?() being
-%   the name for the function call operator
-% + it is possible to easily search for all constructors in a project
-%   and immediately know that a function is a constructor by seeing the
-%   name "?{}"
-% A destructor is declared with the name ^?{}
-% + name mirrors a constructor's name, with an extra symbol to
-%   distinguish it
-% - the symbol '~' cannot be used due to parsing conflicts with the
-%   unary '~' (bitwise negation) operator - this conflict exists because
-%   we want to allow users to write ^x{}; to destruct x, rather than
-%   ^?{}(&x);
-% The first argument of a constructor must be a pointer. The constructed
-% type is the base type of the pointer. E.g. void ?{}(T *) is a default
-% constructor for a T.
-% + can name the argument whatever you like, so not constrained by
-%   language keyword "this" or "self", etc.
-% - have to explicitly qualify all object members to initialize them
-%   (e.g. this->x = 0, rather than just x = 0)
-% Destructors can take arguments other than just the destructed pointer
-% * open research problem: not sure how useful this is
-% Pointer constructors
-% + can construct separately compiled objects (opaque types) [6]
-% + orthogonal design, follows directly from the definition of the first
-%   argument of a constructor
-% - may require copy constructor or move constructor (or equivalent)
-%   for correct implementation, which may not be obvious to everyone
-% + required feature for the prelude to specify as much behavior as possible
-%   (similar to pointer assignment operators in this respect)
-% Designations can only be used for C-style initialization
-% * designation for constructors is equivalent to designation for any
-%   general function call. Since a function prototype can be redeclared
-%   many times, with arguments named differently each time (or not at
-%   all!), this is considered to be an undesirable feature. We could
-%   construct some set of rules to allow this behaviour, but it is
-%   probably more trouble than it's worth, and no matter what we choose,
-%   it is not likely to be obvious to most people.
-% Constructing an anonymous member [7]
-% + same as with calling any other function on an anonymous member
-%   (implicit conversion by the compiler)
-% - may be some cases where this is ambiguous => clarify with a cast
-%   (try to design APIs to avoid sharing function signatures between
-%   composed types to avoid this)
-% Default Constructors and Destructors are called implicitly
-% + cannot forget to construct or destruct an object
-% - requires special syntax to specify that an object is not to be
-%   constructed (@=)
-% * an object will not be implicitly constructed OR destructed if
-%   explicitly initialized like a C object (@= syntax)
-% * an object will be destructed if there are no constructors in scope
-%   (even though it is initialized like a C object) [8]
-% An object which changes from POD type to non POD type will not change
-% the semantics of a type containing it by composition
-% * That is, constructors will not be regenerated at the point where
-%   an object changes from POD type to non POD type, because this could
-%   cause a cascade of constructors being regenerated for many other
-%   types. Further, there is precedence for this behaviour in other
-%   facets of Cforall's design, such as how nested functions interact.
-% * This behaviour can be simplified in a language without declaration
-%   before use, because a type can be classified as POD or non POD
-%   (rather than potentially changing between the two at some point) at
-%   at the global scope (which is likely the most common case)
-% * [9]
-% Changes to polymorphic type classes
-% * dtype and ftype remain the same
-% * forall(otype T) is currently essentially the same as
-%   forall(dtype T | { @size(T); void ?=?(T *, T); }).
-%   The big addition is that you can declare an object of type T, rather
-%   than just a pointer to an object of type T since you know the size,
-%   and you can assign into a T.
-%   * this definition is changed to add default constructor and
-%     destructor declarations, to remain consistent with what type meant
-%     before the introduction of constructors and destructors.
-%     * that is, forall(type T) is now essentially the same as
-%       forall(dtype T | { @size(T); void ?=?(T *, T);
-%                          void ?{}(T *); void ^?{}(T *); })
-%     + this is required to make generic types work correctly in
-%       polymorphic functions
-%     ? since declaring a constructor invalidates the autogenerated
-%       routines, it is possible for a type to have constructors, but
-%       not default constructors. That is, it might be the case that
-%       you want to write a polymorphic function for a type which has
-%       a size, but non-default constructors? Some options:
-%       * declaring a constructor as a part of the assertions list for
-%         a type declaration invalidates the default, so
-%         forall(otype T | { void ?{}(T *, int); })
-%         really means
-%         forall(dtype T | { @size(T); void ?=?(T *, T);
-%                            void ?{}(T *, int); void ^?{}(T *); })
-%       * force users to fully declare the assertions list like the
-%         above in this case (this seems very undesirable)
-%       * add another type class with the current desugaring of type
-%         (just size and assignment)
-%       * provide some way of subtracting from an existing assertions
-%         list (this might be useful to have in general)
-% Implementation issues:
-% Changes to prelude/autogen or built in defaults?
-% * pointer ctors/dtors [prelude]
-%   * other pointer type routines are declared in the prelude, and this
-%     doesn't seem like it should be any different
-% * basic type ctors/dtors [prelude]
-%   * other basic type routines are declared in the prelude, and this
-%     doesn't seem like it should be any different
-% ? aggregate types [undecided, but leaning towards autogenerate]
-%   * prelude
-%     * routines specific to aggregate types cannot be predeclared in
-%       the prelude because we don't know the name of every
-%       aggregate type in the entire program
-%   * autogenerate
-%     + default assignment operator is already autogenerated for
-%       aggregate types
-%       * this seems to lead us in the direction of autogenerating,
-%         because we may have a struct which contains other objects
-%         that require construction [10]. If we choose not to
-%         autogenerate in this case, then objects which are part of
-%         other objects by composition will not be constructed unless
-%         a constructor for the outer type is explicitly defined
-%       * in this case, we would always autogenerate the appropriate
-%         constructor(s) for an aggregate type, but just like with
-%         basic types, pointer types, and enum types, the constructor
-%         call can be elided when when it is not necessary.
-%     + constructors will have to be explicitly autogenerated
-%       in the case where they are required for a polymorphic function,
-%       when no user defined constructor is in scope, which may make it
-%       easiest to always autogenerate all appropriate constructors
-%     - n+2 constructors would have to be generated for a POD type
-%       * one constructor for each number of valid arguments [0, n],
-%         plus the copy constructor
-%         * this is taking a simplified approach: in C, it is possible
-%           to omit the enclosing braces in a declaration, which would
-%           lead to a combinatorial explosion of generated constructors.
-%           In the interest of keeping things tractable, Cforall may be
-%           incompatible with C in this case. [11]
-%       * for non-POD types, only autogenerate the default and copy
-%         constructors
-%       * alternative: generate only the default constructor and
-%         special case initialization for any other constructor when
-%         only the autogenerated one exists
-%         - this is not very sensible, as by the previous point, these
-%           constructors may be needed for polymorphic functions
-%           anyway.
-%     - must somehow distinguish in resolver between autogenerated and
-%       user defined constructors (autogenerated should never be chosen
-%       when a user defined option exists [check first parameter], even
-%       if full signature differs) (this may also have applications
-%       to other autogenerated routines?)
-%     - this scheme does not naturally support designation (i.e. general
-%       functions calls do not support designation), thus these cases
-%       will have to be treated specially in either case
-%   * defaults
-%     * i.e. hardcode a new set of rules for some "appropriate" default
-%       behaviour for
-%     + when resolving an initialization expression, explicitly check to
-%       see if any constructors are in scope. If yes, attempt to resolve
-%       to a constructor, and produce an error message if a match is not
-%       found. If there are no constructors in scope, resolve to
-%       initializing each field individually (C-style)
-%     + does not attempt to autogenerate constructors for POD types,
-%       which can be seen as a space optimization for the program
-%       binary
-%     - as stated previously, a polymorphic routine may require these
-%       autogenerated constructors, so this doesn't seem like a big win,
-%       because this leads to more complicated logic and tracking of
-%       which constructors have already been generated
-%     - even though a constructor is not explicitly declared or used
-%       polymorphically, we might still need one for all uses of a
-%       struct (e.g. in the case of composition).
-%   * the biggest tradeoff in autogenerating vs. defaulting appears to
-%     be in where and how the special code to check if constructors are
-%     present is handled. It appears that there are more reasons to
-%     autogenerate than not.
-% --- examples
-% [1] As an example of using constructors polymorphically, consider a
-% slight modification on the foldl example I put on the mailing list a
-% few months ago:
-% context iterable(type collection, type element, type iterator) {
-%   void ?{}(iterator *, collection); // used to be makeIterator, but can
-%                             // idiomatically use constructor
-%   int hasNext(iterator);
-%   iterator ++?(iterator *);
-%   lvalue element *?(iterator);
-% };
-% forall(type collection, type element, type result, type iterator
-%   | iterable(collection, element, iterator))
-% result foldl(collection c, result acc,
-%     result (*reduce)(result, element)) {
-%   iterator it = { c };
-%   while (hasNext(it)) {
-%     acc = reduce(acc, *it);
-%     ++it;
-%   }
-%   return acc;
-% }
-% Now foldl makes use of the knowledge that the iterator type has a
-% single argument constructor which takes the collection to iterate
-% over. This pattern allows polymorphic code to look more natural
-% (constructors are generally preferred to named initializer/creation
-% routines, e.g. "makeIterator")
-% [2] An example of some potentially dangerous code that we don't want
-% to let easily slip through the cracks - if this is really what you
-% want, then use @= syntax for the second declaration to quiet the
-% compiler.
-% struct A { int x, y, z; }
-% ?{}(A *, int);
-% ?{}(A *, int, int, int);
-% A a1 = { 1 };         // uses ?{}(A *, int);
-% A a2 = { 2, 3 };      // C-style initialization -> no invariants!
-% A a3 = { 4, 5, 6 };   // uses ?{}(A *, int, int, int);
-% [3] Since @= syntax creates a C object (essentially a POD, as far as
-% the compiler is concerned), the object will not be destructed
-% implicitly when it leaves scope, nor will it be copy constructed when
-% it is returned. In this case, a memcpy should be equivalent to a move.
-% // Box.h
-% struct Box;
-% void ?{}(Box **, int};
-% void ^?{}(Box **);
-% Box * make_fortytwo();
-% // Box.cfa
-% Box * make_fortytwo() {
-%   Box *b @= {};
-%   (&b){ 42 }; // construct explicitly
-%   return b; // no destruction, essentially a move?
-% }
-% [4] Cforall's typesafe malloc can be composed with constructor
-% expressions. It is possible for a user to define their own functions
-% similar to malloc and achieve the same effects (e.g. Aaron's example
-% of an arena allocator)
-% // CFA malloc
-% forall(type T)
-% T * malloc() { return (T *)malloc(sizeof(T)); }
-% struct A { int x, y, z; };
-% void ?{}(A *, int);
-% int foo(){
-%   ...
-%   // desugars to:
-%   // A * a = ?{}(malloc(), 123);
-%   A * a = malloc() { 123 };
-%   ...
-% }
-% [5] Aaron's example of combining function calls with constructor
-% syntax to perform an operation similar to C++'s std::vector::emplace
-% (i.e. to construct a new element in place, without the need to
-% copy)
-% forall(type T)
-% struct vector {
-%   T * elem;
-%   int len;
-%   ...
-% };
-% ...
-% forall(type T)
-% T * vector_new(vector(T) * v) {
-%   // reallocate if needed
-%   return &v->elem[len++];
-% }
-% int main() {
-%   vector(int) * v = ...
-%   vector_new(v){ 42 };  // add element to the end of vector
-% }
-% [6] Pointer Constructors. It could be useful to use the existing
-% constructor syntax even more uniformly for ADTs. With this, ADTs can
-% be initialized in the same manor as any other object in a polymorphic
-% function.
-% // vector.h
-% forall(type T) struct vector;
-% forall(type T) void ?{}(vector(T) **);
-% // adds an element to the end
-% forall(type T) vector(T) * ?+?(vector(T) *, T);
-% // vector.cfa
-% // don't want to expose the implementation to the user and/or don't
-% // want to recompile the entire program if the struct definition
-% // changes
-% forall(type T) struct vector {
-%   T * elem;
-%   int len;
-%   int capacity;
-% };
-% forall(type T) void resize(vector(T) ** v) { ... }
-% forall(type T) void ?{}(vector(T) ** v) {
-%   vector(T) * vect = *v = malloc();
-%   vect->capacity = 10;
-%   vect->len = 0;
-%   vect->elem = malloc(vect->capacity);
-% }
-% forall(type T) vector(T) * ?+?(vector(T) *v, T elem) {
-%   if (v->len == v->capacity) resize(&v);
-%   v->elem[v->len++] = elem;
-% }
-% // main.cfa
-% #include "adt.h"
-% forall(type T | { T ?+?(T, int); }
-% T sumRange(int lower, int upper) {
-%   T x;    // default construct
-%   for (int i = lower; i <= upper; i++) {
-%     x = x + i;
-%   }
-%   return x;
-% }
-% int main() {
-%   vector(int) * numbers = sumRange(1, 10);
-%   // numbers is now a vector containing [1..10]
-%   int sum = sumRange(1, 10);
-%   // sum is now an int containing the value 55
-% }
-% [7] The current proposal is to use the plan 9 model of inheritance.
-% Under this model, all of the members of an unnamed struct instance
-% become members of the containing struct. In addition, an object
-% can be passed as an argument to a function expecting one of its
-% base structs.
-% struct Point {
-%   double x;
-%   double y;
-% };
-% struct ColoredPoint {
-%   Point;        // anonymous member (no identifier)
-%                 // => a ColoredPoint has an x and y of type double
-%   int color;
-% };
-% ColoredPoint cp = ...;
-% cp.x = 10.3;    // x from Point is accessed directly
-% cp.color = 0x33aaff; // color is accessed normally
-% foo(cp);        // cp can be used directly as a Point
-% void ?{}(Point *p, double x, double y) {
-%   p->x = x;
-%   p->y = y;
-% }
-% void ?{}(ColoredPoint *cp, double x, double y, int color) {
-%   (&cp){ x, y };  // unambiguous, no ?{}(ColoredPoint*,double,double)
-%   cp->color = color;
-% }
-% struct Size {
-%   double width;
-%   double height;
-% };
-% void ?{}(Size *s, double w, double h) {
-%   p->width = w;
-%   p->height = h;
-% }
-% struct Foo {
-%   Point;
-%   Size;
-% }
-% ?{}(Foo &f, double x, double y, double w, double h) {
-%   // (&F,x,y) is ambiguous => is it ?{}(Point*,double,double) or
-%   // ?{}(Size*,double,double)? Solve with a cast:
-%   ((Point*)&F){ x, y };
-%   ((Size*)&F){ w, h };
-% }
-% [8] Destructors will be called on objects that were not constructed.
-% struct A { ... };
-% ^?{}(A *);
-% {
-%   A x;
-%   A y @= {};
-% } // x is destructed, even though it wasn't constructed
-%   // y is not destructed, because it is explicitly a C object
-% [9] A type's constructor is generated at declaration time using
-% current information about an object's members. This is analogous to
-% the treatment of other operators. For example, an object's assignment
-% operator will not change to call the override of a member's assignment
-% operator unless the object's assignment is also explicitly overridden.
-% This problem can potentially be treated differently in Do, since each
-% compilation unit is passed over at least twice (once to gather
-% symbol information, once to generate code - this is necessary to
-% achieve the "No declarations" goal)
-% struct A { ... };
-% struct B { A x; };
-% ...
-% void ?{}(A *);  // from this point on, A objects will be constructed
-% B b1;           // b1 and b1.x are both NOT constructed, because B
-%                 // objects are not constructed
-% void ?{}(B *);  // from this point on, B objects will be constructed
-% B b2;           // b2 and b2.x are both constructed
-% struct C { A x; };
-% // implicit definition of ?{}(C*), because C is not a POD type since
-% // it contains a non-POD type by composition
-% C c;            // c and c.x are both constructed
-% [10] Requiring construction by composition
-% struct A {
-%   ...
-% };
-% // declared ctor disables default c-style initialization of
-% // A objects; A is no longer a POD type
-% void ?{}(A *);
-% struct B {
-%   A x;
-% };
-% // B objects can not be C-style initialized, because A objects
-% // must be constructed => B objects are transitively not POD types
-% B b; // b.x must be constructed, but B is not constructible
-%      // => must autogenerate ?{}(B *) after struct B definition,
-%      // which calls ?{}(&b.x)
-% [11] Explosion in the number of generated constructors, due to strange
-% C semantics.
-% struct A { int x, y; };
-% struct B { A u, v, w; };
-% A a = { 0, 0 };
-% // in C, you are allowed to do this
-% B b1 = { 1, 2, 3, 4, 5, 6 };
-% B b2 = { 1, 2, 3 };
-% B b3 = { a, a, a };
-% B b4 = { a, 5, 4, a };
-% B b5 = { 1, 2, a, 3 };
-% // we want to disallow b1, b2, b4, and b5 in Cforall.
-% // In particular, we will autogenerate these constructors:
-% void ?{}(A *);             // default/0 parameters
-% void ?{}(A *, int);        // 1 parameter
-% void ?{}(A *, int, int);   // 2 parameters
-% void ?{}(A *, const A *);  // copy constructor
-% void ?{}(B *);             // default/0 parameters
-% void ?{}(B *, A);          // 1 parameter
-% void ?{}(B *, A, A);       // 2 parameters
-% void ?{}(B *, A, A, A);    // 3 parameters
-% void ?{}(B *, const B *);  // copy constructor
-% // we will not generate constructors for every valid combination
-% // of members in C. For example, we will not generate
-% void ?{}(B *, int, int, int, int, int, int);   // b1 would need this
-% void ?{}(B *, int, int, int);                  // b2 would need this
-% void ?{}(B *, A, int, int, A);                 // b4 would need this
-% void ?{}(B *, int, int, A, int);               // b5 would need this
-% // and so on
 Since \CFA is a true systems language, it does not provide a garbage collector.
 …
 This chapter details the design of constructors and destructors in \CFA, along with their current implementation in the translator.
 Generated code samples have been edited to provide comments for clarity and to save on space.
+Generated code samples have been edited for clarity and brevity.
 \section{Design Criteria}
 …
 Use of uninitialized variables yields undefined behaviour, which is a common source of errors in C programs.
+Declaration initialization is insufficient, because it permits uninitialized variables to exist and because it does not allow for the insertion of arbitrary code before a variable is live.
+Initialization of a declaration is strictly optional, permitting uninitialized variables to exist.
+Furthermore, declaration initialization is limited to expressions, so there is no way to insert arbitrary code before a variable is live, without delaying the declaration.
 Many C compilers give good warnings for uninitialized variables most of the time, but they cannot in all cases.
 \begin{cfacode}
 …
 Other languages are able to give errors in the case of uninitialized variable use, but due to backwards compatibility concerns, this is not the case in \CFA.
 In C, constructors and destructors are often mimicked by providing routines that create and teardown objects, where the teardown function is typically only necessary if the type modifies the execution environment.
+In C, constructors and destructors are often mimicked by providing routines that create and tear down objects, where the tear down function is typically only necessary if the type modifies the execution environment.
 \begin{cfacode}
 struct array_int {
 …
 Furthermore, even with this idiom it is easy to make mistakes, such as forgetting to destroy an object or destroying it multiple times.
 A constructor provides a way of ensuring that the necessary aspects of object initialization is performed, from setting up invariants to providing compile-time checks for appropriate initialization parameters.
+A constructor provides a way of ensuring that the necessary aspects of object initialization is performed, from setting up invariants to providing compile- and run-time checks for appropriate initialization parameters.
 This goal is achieved through a guarantee that a constructor is called implicitly after every object is allocated from a type with associated constructors, as part of an object's definition.
 Since a constructor is called on every object of a managed type, it is impossible to forget to initialize such objects, as long as all constructors perform some sensible form of initialization.
 …
 In other words, a default constructor is a constructor that takes a single argument: the @this@ parameter.
 In \CFA, a destructor is a function much like a constructor, except that its name is \lstinline!^?{}!.
+In \CFA, a destructor is a function much like a constructor, except that its name is \lstinline!^?{}! and it take only one argument.
 A destructor for the @Array@ type can be defined as such.
 \begin{cfacode}
 …
 It is possible to define a constructor that takes any combination of parameters to provide additional initialization options.
 For example, a reasonable extension to the array type would be a constructor that allocates the array to a given initial capacity and initializes the array to a given @fill@ value.
+For example, a reasonable extension to the array type would be a constructor that allocates the array to a given initial capacity and initializes the elements of the array to a given @fill@ value.
 \begin{cfacode}
 void ?{}(Array * arr, int capacity, int fill) {
 …
 One of these three syntactic forms should appeal to either C or \CC programmers using \CFA.
+\subsection{Constructor Expressions}
+In \CFA, it is possible to use a constructor as an expression.
+Like other operators, the function name @?{}@ matches its operator syntax.
+For example, @(&x){}@ calls the default constructor on the variable @x@, and produces @&x@ as a result.
+A key example for this capability is the use of constructor expressions to initialize the result of a call to standard C routine @malloc@.
+\begin{cfacode}
+struct X { ... };
+void ?{}(X *, double);
+X * x = malloc(sizeof(X)){ 1.5 };
+\end{cfacode}
+In this example, @malloc@ dynamically allocates storage and initializes it using a constructor, all before assigning it into the variable @x@.
+If this extension is not present, constructing dynamically allocated objects is much more cumbersome, requiring separate initialization of the pointer and initialization of the pointed-to memory.
+\begin{cfacode}
+X * x = malloc(sizeof(X));
+x{ 1.5 };
+\end{cfacode}
+Not only is this verbose, but it is also more error prone, since this form allows maintenance code to easily sneak in between the initialization of @x@ and the initialization of the memory that @x@ points to.
+This feature is implemented via a transformation producing the value of the first argument of the constructor, since constructors do not themselves have a return value.
+Since this transformation results in two instances of the subexpression, care is taken to allocate a temporary variable to hold the result of the subexpression in the case where the subexpression may contain side effects.
+The previous example generates the following code.
+\begin{cfacode}
+struct X *_tmp_ctor;
+struct X *x = ?{}(  // construct result of malloc
+  _tmp_ctor=malloc(sizeof(struct X)), // store result of malloc
+.5
+), _tmp_ctor; // produce constructed result of malloc
+\end{cfacode}
+It should be noted that this technique is not exclusive to @malloc@, and allows a user to write a custom allocator that can be idiomatically used in much the same way as a constructed @malloc@ call.
+It is also possible to use operator syntax with destructors.
+Unlike constructors, operator syntax with destructors is a statement and thus does not produce a value, since the destructed object is invalidated by the use of a destructor.
+For example, \lstinline!^(&x){}! calls the destructor on the variable @x@.
 \subsection{Function Generation}
 In \CFA, every type is defined to have the core set of four functions described previously.
+In \CFA, every type is defined to have the core set of four special functions described previously.
 Having these functions exist for every type greatly simplifies the semantics of the language, since most operations can simply be defined directly in terms of function calls.
 In addition to simplifying the definition of the language, it also simplifies the analysis that the translator must perform.
 …
 The generated functions for enumerations are the simplest.
 Since enumerations in C are essentially just another integral type, the generated functions behave in the same way that the builtin functions for the basic types work.
+Since enumerations in C are essentially just another integral type, the generated functions behave in the same way that the built-in functions for the basic types work.
 For example, given the enumeration
 \begin{cfacode}
 …
+}
 void ?{}(enum Colour *_dst, enum Colour _src){
   (*_dst)=_src;  // bitwise copy
+  *_dst=_src;  // bitwise copy
+}
 void ^?{}(enum Colour *_dst){
 …
+}
 enum Colour ?=?(enum Colour *_dst, enum Colour _src){
   return (*_dst)=_src; // bitwise copy
+  return *_dst=_src; // bitwise copy
+}
 \end{cfacode}
 …
 For copy constructor and assignment operations, a bitwise @memcpy@ is applied.
 In standard C, a union can also be initialized using a value of the same type as its first member, and so a corresponding field constructor is generated to perform a bitwise @memcpy@ of the object.
 An alterantive to this design is to always construct and destruct the first member of a union, to match with the C semantics of initializing the first member of the union.
+An alternative to this design is to always construct and destruct the first member of a union, to match with the C semantics of initializing the first member of the union.
 This approach ultimately feels subtle and unsafe.
 Another option is to, like \CC, disallow unions from containing members that are themselves managed types.
 …
 Instead, @a2->x@ is initialized to @0@ as if it were a C object, because of the explicit initializer.
 In addition to freedom, \ateq provides a simple path to migrating legacy C code to Cforall, in that objects can be moved from C-style initialization to \CFA gradually and individually.
+In addition to freedom, \ateq provides a simple path to migrating legacy C code to \CFA, in that objects can be moved from C-style initialization to \CFA gradually and individually.
 It is worth noting that the use of unmanaged objects can be tricky to get right, since there is no guarantee that the proper invariants are established on an unmanaged object.
 It is recommended that most objects be managed by sensible constructors and destructors, except where absolutely necessary.
 …
 When defining a constructor or destructor for a struct @S@, any members that are not explicitly constructed or destructed are implicitly constructed or destructed automatically.
 If an explicit call is present, then that call is taken in preference to any implicitly generated call.
 A consequence of this rule is that it is possible, unlike \CC, to precisely control the order of construction and destruction of subobjects on a per-constructor basis, whereas in \CC subobject initialization and destruction is always performed based on the declaration order.
+A consequence of this rule is that it is possible, unlike \CC, to precisely control the order of construction and destruction of sub-objects on a per-constructor basis, whereas in \CC sub-object initialization and destruction is always performed based on the declaration order.
 \begin{cfacode}
 struct A {
 …
+}
 \end{cfacode}
 Finally, it is illegal for a subobject to be explicitly constructed for the first time after it is used for the first time.
+Finally, it is illegal for a sub-object to be explicitly constructed for the first time after it is used for the first time.
 If the translator cannot be reasonably sure that an object is constructed prior to its first use, but is constructed afterward, an error is emitted.
 More specifically, the translator searches the body of a constructor to ensure that every subobject is initialized.
+More specifically, the translator searches the body of a constructor to ensure that every sub-object is initialized.
 \begin{cfacode}
 void ?{}(A * a, double x) {
 …
+}
 \end{cfacode}
 However, if the translator sees a subobject used within the body of a constructor, but does not see a constructor call that uses the subobject as the target of a constructor, then the translator assumes the object is to be implicitly constructed (copy constructed in a copy constructor and default constructed in any other constructor).
+However, if the translator sees a sub-object used within the body of a constructor, but does not see a constructor call that uses the sub-object as the target of a constructor, then the translator assumes the object is to be implicitly constructed (copy constructed in a copy constructor and default constructed in any other constructor).
 \begin{cfacode}
 void ?{}(A * a) {
 …
 } // z, y, w implicitly destructed, in this order
 \end{cfacode}
 If at any point, the @this@ parameter is passed directly as the target of another constructor, then it is assumed that constructor handles the initialization of all of the object's members and no implicit constructor calls are added. % TODO: this is basically always wrong. if anything, I should check that such a constructor does not initialize any members, otherwise it'll always initialize the member twice (once locally, once by the called constructor). This might be okay in some situations, but it deserves a warning at the very least.
+If at any point, the @this@ parameter is passed directly as the target of another constructor, then it is assumed that constructor handles the initialization of all of the object's members and no implicit constructor calls are added.
 To override this rule, \ateq can be used to force the translator to trust the programmer's discretion.
 This form of \ateq is not yet implemented.
 …
 };
 \end{cfacode}
 In C, nesting initializers means that the programmer intends to initialize subobjects with the nested initializers.
+In C, nesting initializers means that the programmer intends to initialize sub-objects with the nested initializers.
 The reason for this omission is to both simplify the mental model for using constructors, and to make initialization simpler for the expression resolver.
 If this were allowed, it would be necessary for the expression resolver to decide whether each argument to the constructor call could initialize to some argument in one of the available constructors, making the problem highly recursive and potentially much more expensive.
 …
+}
 \end{cfacode}
-% TODO: in CFA if the array dimension is empty, no object constructors are added -- need to fix this.
 The body of @A@ has been omitted, since only the constructor interfaces are important.
 …
     if (i == 2) return; // destruct x, y
   } // destruct y
+}
+} // destruct x
 \end{cfacode}
 …
 Since a destructor call is automatically inserted at the end of the block, nothing special needs to happen to destruct @x@ in the case where control reaches the end of the loop.
 In the case where @i@ is @2@, the continue statement runs the loop update expression and attempts to begin the next iteration of the loop.
 Since continue is a C statement, which does not understand destructors, a destructor call is added just before the continue statement to ensure that @x@ is destructed.
+Since continue is a C statement, which does not understand destructors, it is transformed into a @goto@ statement that branches to the end of the loop, just before the block's destructors, to ensure that @x@ is destructed.
 When @i@ is @3@, the break statement moves control to just past the end of the loop.
 Like the previous case, a destructor call for @x@ is inserted just before the break statement.
 \CFA also supports labelled break and continue statements, which allow more precise manipulation of control flow.
 Labelled break and continue allow the programmer to specify which control structure to target by using a label attached to a control structure.
+Unlike the previous case, the destructor for @x@ cannot be reused, so a destructor call for @x@ is inserted just before the break statement.
+\CFA also supports labeled break and continue statements, which allow more precise manipulation of control flow.
+Labeled break and continue allow the programmer to specify which control structure to target by using a label attached to a control structure.
 \begin{cfacode}[emph={L1,L2}, emphstyle=\color{red}]
 L1: for (int i = 0; i < 10; i++) {
 …
 \end{cfacode}
 The statement @continue L1@ begins the next iteration of the outer for-loop.
+Since the semantics of continue require the loop update expression to execute, control branches to the \emph{end} of the outer for loop, meaning that the block destructor for @x@ can be reused, and it is only necessary to generate the destructor for @y@.
+% TODO: "why not do this all the time? fix or justify"
+Break, on the other hand, requires jumping out of the loop, so the destructors for both @x@ and @y@ are generated and inserted before the @break L1@ statement.
+Since the semantics of continue require the loop update expression to execute, control branches to the end of the outer for loop, meaning that the block destructor for @x@ can be reused, and it is only necessary to generate the destructor for @y@.
+Break, on the other hand, requires jumping out of both loops, so the destructors for both @x@ and @y@ are generated and inserted before the @break L1@ statement.
 Finally, an example which demonstrates goto.
 …
+}
 \end{cfacode}
 Labelled break and continue are implemented in \CFA in terms of goto statements, so the more constrained forms are precisely goverened by these rules.
+All break and continue statements are implemented in \CFA in terms of goto statements, so the more constrained forms are precisely governed by these rules.
 The next example demonstrates the error case.
 …
 \subsection{Implicit Copy Construction}
+\label{s:implicit_copy_construction}
 When a function is called, the arguments supplied to the call are subject to implicit copy construction (and destruction of the generated temporary), and the return value is subject to destruction.
 When a value is returned from a function, the copy constructor is called to pass the value back to the call site.
 Exempt from these rules are intrinsic and builtin functions.
+Exempt from these rules are intrinsic and built-in functions.
 It should be noted that unmanaged objects are subject to copy constructor calls when passed as arguments to a function or when returned from a function, since they are not the \emph{target} of the copy constructor call.
 That is, since the parameter is not marked as an unmanaged object using \ateq, it will be copy constructed if it is returned by value or passed as an argument to another function, so to guarantee consistent behaviour, unmanaged objects must be copy constructed when passed as arguments.
 …
 It should be noted that reference types will allow specifying that a value does not need to be copied, however reference types do not provide a means of preventing implicit copy construction from uses of the reference, so the problem is still present when passing or returning the reference by value.
 A known issue with this implementation is that the return value of a function is not guaranteed to have the same address for its entire lifetime.
 Specifically, since @_retval_f@ is allocated and constructed in @f@ then returned by value, the internal data is bitwise copied into the caller's stack frame.
+A known issue with this implementation is that the argument and return value temporaries are not guaranteed to have the same address for their entire lifetimes.
+In the previous example, since @_retval_f@ is allocated and constructed in @f@, then returned by value, the internal data is bitwise copied into the caller's stack frame.
 This approach works out most of the time, because typically destructors need to only access the fields of the object and recursively destroy.
 It is currently the case that constructors and destructors that use the @this@ pointer as a unique identifier to store data externally do not work correctly for return value objects.
 Thus, it is not safe to rely on an object's @this@ pointer to remain constant throughout execution of the program.
+Thus, it is currently not safe to rely on an object's @this@ pointer to remain constant throughout execution of the program.
 \begin{cfacode}
 A * external_data[32];
 …
 \end{cfacode}
 In the above example, a global array of pointers is used to keep track of all of the allocated @A@ objects.
 Due to copying on return, the current object being destructed does not exist in the array if an @A@ object is ever returned by value from a function.
+Due to copying on return, the current object being destructed does not exist in the array if an @A@ object is ever returned by value from a function, such as in @makeA@.
 This problem could be solved in the translator by changing the function signatures so that the return value is moved into the parameter list.
 …
 \end{cfacode}
 An alternative is to instead make the attribute \emph{identifiable}, which states that objects of this type use the @this@ parameter as an identity.
 This strikes more closely to the visibile problem, in that only types marked as identifiable would need to have the return value moved into the parameter list, and every other type could remain the same.
+This strikes more closely to the visible problem, in that only types marked as identifiable would need to have the return value moved into the parameter list, and every other type could remain the same.
 Furthermore, no restrictions would need to be placed on whether objects can be constructed.
 \begin{cfacode}
 …
 \end{cfacode}
 Ultimately, this is the type of transformation that a real compiler would make when generating assembly code.
 Since a compiler has full control over its calling conventions, it can seamlessly allow passing the return parameter without outwardly changing the signature of a routine.
 As such, it has been decided that this issue is not currently a priority.
+Ultimately, both of these are patchwork solutions.
+Since a real compiler has full control over its calling conventions, it can seamlessly allow passing the return parameter without outwardly changing the signature of a routine.
+As such, it has been decided that this issue is not currently a priority and will be fixed when a full \CFA compiler is implemented.
 \section{Implementation}
 …
 It is, however, guaranteed that any global objects in the standard library are initialized prior to the initialization of any object in the user program.
 This feature is implemented in the \CFA translator by grouping every global constructor call into a function with the GCC attribute \emph{constructor}, which performs most of the heavy lifting. % TODO: CITE: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
+This feature is implemented in the \CFA translator by grouping every global constructor call into a function with the GCC attribute \emph{constructor}, which performs most of the heavy lifting \cite[6.31.1]{GCCExtensions}.
 A similar function is generated with the \emph{destructor} attribute, which handles all global destructor calls.
 At the time of writing, initialization routines in the library are specified with priority \emph{101}, which is the highest priority level that GCC allows, whereas initialization routines in the user's code are implicitly given the default priority level, which ensures they have a lower priority than any code with a specified priority level.
 This mechanism allows arbitrarily complicated initialization to occur before any user code runs, making it possible for library designers to initialize their modules without requiring the user to call specific startup or teardown routines.
+This mechanism allows arbitrarily complicated initialization to occur before any user code runs, making it possible for library designers to initialize their modules without requiring the user to call specific startup or tear-down routines.
 For example, given the following global declarations.
 …
 %   https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes
 % suggestion: implement this in CFA by picking objects with a specified priority and pulling them into their own init functions (could even group them by priority level -> map<int, list<ObjectDecl*>>) and pull init_priority forward into constructor and destructor attributes with the same priority level
 GCC provides an attribute @init_priority@, which specifies allows specifying the relative priority for initialization of global objects on a per-object basis in \CC.
+GCC provides an attribute @init_priority@, which allows specifying the relative priority for initialization of global objects on a per-object basis in \CC.
 A similar attribute can be implemented in \CFA by pulling marked objects into global constructor/destructor-attribute functions with the specified priority.
 For example,
 …
 \subsection{Static Local Variables}
 In standard C, it is possible to mark variables that are local to a function with the @static@ storage class.
 Unlike normal local variables, a @static@ local variable is defined to live for the entire duration of the program, so that each call to the function has access to the same variable with the same address and value as it had in the previous call to the function. % TODO: mention dynamic loading caveat??
+Unlike normal local variables, a @static@ local variable is defined to live for the entire duration of the program, so that each call to the function has access to the same variable with the same address and value as it had in the previous call to the function.
 Much like global variables, in C @static@ variables can only be initialized to a \emph{compile-time constant value} so that a compiler is able to create storage for the variable and initialize it at compile-time.
 …
 Construction of @static@ local objects is implemented via an accompanying @static bool@ variable, which records whether the variable has already been constructed.
 A conditional branch checks the value of the companion @bool@, and if the variable has not yet been constructed then the object is constructed.
 The object's destructor is scheduled to be run when the program terminates using @atexit@, and the companion @bool@'s value is set so that subsequent invocations of the function do not reconstruct the object.
+The object's destructor is scheduled to be run when the program terminates using @atexit@ \footnote{When using the dynamic linker, it is possible to dynamically load and unload a shared library. Since glibc 2.2.3 \cite{atexit}, functions registered with @atexit@ within the shared library are called when unloading the shared library. As such, static local objects can be destructed using this mechanism even in shared libraries on Linux systems.}, and the companion @bool@'s value is set so that subsequent invocations of the function do not reconstruct the object.
 Since the parameter to @atexit@ is a parameter-less function, some additional tweaking is required.
 First, the @static@ variable must be hoisted up to global scope and uniquely renamed to prevent name clashes with other global objects.
 …
 Finally, the newly generated function is registered with @atexit@, instead of registering the destructor directly.
 Since @atexit@ calls functions in the reverse order in which they are registered, @static@ local variables are guaranteed to be destructed in the reverse order that they are constructed, which may differ between multiple executions of the same program.
 Extending the previous example
 \begin{cfacode}
 …
 \end{cfacode}
+% TODO: move this section forward?? maybe just after constructor syntax? would need to remove _tmp_cp_ret0, since copy constructors are not discussed yet, but this might not be a big issue.
+\subsection{Constructor Expressions}
+In \CFA, it is possible to use a constructor as an expression.
+Like other operators, the function name @?{}@ matches its operator syntax.
+For example, @(&x){}@ calls the default constructor on the variable @x@, and produces @&x@ as a result.
+A key example for this capability is the use of constructor expressions to initialize the result of a call to standard C routine @malloc@.
+\begin{cfacode}
+struct X { ... };
+void ?{}(X *, double);
+X * x = malloc(sizeof(X)){ 1.5 };
+\end{cfacode}
+In this example, @malloc@ dynamically allocates storage and initializes it using a constructor, all before assigning it into the variable @x@.
+If this extension is not present, constructing dynamically allocated objects is much more cumbersome, requiring separate initialization of the pointer and initialization of the pointed-to memory.
+\begin{cfacode}
+X * x = malloc(sizeof(X));
+x{ 1.5 };
+\end{cfacode}
+Not only is this verbose, but it is also more error prone, since this form allows maintenance code to easily sneak in between the initialization of @x@ and the initialization of the memory that @x@ points to.
+This feature is implemented via a transformation produceing the value of the first argument of the constructor, since constructors do not themslves have a return value.
+Since this transformation results in two instances of the subexpression, care is taken to allocate a temporary variable to hold the result of the subexpression in the case where the subexpression may contain side effects.
+The previous example generates the following code.
+\begin{cfacode}
+struct X *_tmp_ctor;
+struct X *x = ?{}((_tmp_ctor=((_tmp_cp_ret0=
+  malloc(sizeof(struct X))), _tmp_cp_ret0))), 1.5), _tmp_ctor);
+\end{cfacode}
+It should be noted that this technique is not exclusive to @malloc@, and allows a user to write a custom allocator that can be idiomatically used in much the same way as a constructed @malloc@ call.
+It is also possible to use operator syntax with destructors.
+Unlike constructors, operator syntax with destructors is a statement and thus does not produce a value, since the destructed object is invalidated by the use of a destructor.
+For example, \lstinline!^(&x){}! calls the destructor on the variable @x@.
+\subsection{Polymorphism}
+As mentioned in section \ref{sub:polymorphism}, \CFA currently has 3 type-classes that are used to designate polymorphic data types: @otype@, @dtype@, and @ftype@.
+In previous versions of \CFA, @otype@ was syntactic sugar for @dtype@ with known size/alignment information and an assignment function.
+That is,
+\begin{cfacode}
+forall(otype T)
+void f(T);
+\end{cfacode}
+was equivalent to
+\begin{cfacode}
+forall(dtype T | sized(T) | { T ?=?(T *, T); })
+void f(T);
+\end{cfacode}
+This allows easily specifying constraints that are common to all complete object types very simply.
+Now that \CFA has constructors and destructors, more of a complete object's behaviour can be specified by than was previously possible.
+As such, @otype@ has been augmented to include assertions for a default constructor, copy constructor, and destructor.
+That is, the previous example is now equivalent to
+\begin{cfacode}
+forall(dtype T | sized(T) | { T ?=?(T *, T); void ?{}(T *); void ?{}(T *, T); void ^?{}(T *); })
+void f(T);
+\end{cfacode}
+This allows @f@'s body to create and destroy objects of type @T@, and pass objects of type @T@ as arguments to other functions, following the normal \CFA rules.
+A point of note here is that objects can be missing default constructors (and eventually other functions through deleted functions), so it is important for \CFA programmers to think carefully about the operations needed by their function, as to not over-constrain the acceptable parameter types.

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

Context Navigation

Changeset f92aa32 for doc/rob_thesis/ctordtor.tex

Legend:

doc/rob_thesis/ctordtor.tex

Download in other formats: