Context Navigation

Reverse Diff

ctordtor.tex [7493339:93afb96]

File:

: 1 edited

doc/rob_thesis/ctordtor.tex (modified) (43 diffs)

Legend:

: Unmodified
: Added
: Removed

doc/rob_thesis/ctordtor.tex

-              r7493339
+              r93afb96
 \chapter{Constructors and Destructors}
 %======================================================================
+% TODO: discuss move semantics; they haven't been implemented, but could be. Currently looking at alternative models. (future work)
 % TODO: as an experiment, implement Andrei Alexandrescu's ScopeGuard http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758?pgno=2
 …
 % // and so on
+% TODO: talk somewhere about compound literals?
 Since \CFA is a true systems language, it does not provide a garbage collector.
 As well, \CFA is not an object-oriented programming language, i.e., structures cannot have routine members.
+As well, \CFA is not an object-oriented programming language, i.e. structures cannot have routine members.
 Nevertheless, one important goal is to reduce programming complexity and increase safety.
 To that end, \CFA provides support for implicit pre/post-execution of routines for objects, via constructors and destructors.
+% TODO: this is old. remove or refactor
+% Manual resource management is difficult.
+% Part of the difficulty results from not having any guarantees about the current state of an object.
+% Objects can be internally composed of pointers that may reference resources which may or may not need to be manually released, and keeping track of that state for each object can be difficult for the end user.
+% Constructors and destructors provide a mechanism to bookend the lifetime of an object, allowing the designer of a type to establish invariants for objects of that type.
+% Constructors guarantee that object initialization code is run before the object can be used, while destructors provide a mechanism that is guaranteed to be run immediately before an object's lifetime ends.
+% Constructors and destructors can help to simplify resource management when used in a disciplined way.
+% In particular, when all resources are acquired in a constructor, and all resources are released in a destructor, no resource leaks are possible.
+% This pattern is a popular idiom in several languages, such as \CC, known as RAII (Resource Acquisition Is Initialization).
 This chapter details the design of constructors and destructors in \CFA, along with their current implementation in the translator.
 …
 Next, @x@ is assigned the value of @y@.
 In the last line, @z@ is implicitly initialized to 0 since it is marked @static@.
 The key difference between assignment and initialization being that assignment occurs on a live object (i.e., an object that contains data).
+The key difference between assignment and initialization being that assignment occurs on a live object (i.e. an object that contains data).
 It is important to note that this means @x@ could have been used uninitialized prior to being assigned, while @y@ could not be used uninitialized.
+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.
+Many C compilers give good warnings for uninitialized variables most of the time, but they cannot in all cases.
+\begin{cfacode}
+int f(int *);  // output parameter: never reads, only writes
+int g(int *);  // input parameter: never writes, only reads,
+               // so requires initialized variable
+Use of uninitialized variables yields undefined behaviour, which is a common source of errors in C programs. % TODO: *citation*
+Declaration initialization is insufficient, because it permits uninitialized variables to exist and because it does not allow for the insertion of arbitrary code before the variable is live.
+Many C compilers give good warnings most of the time, but they cannot in all cases.
+\begin{cfacode}
+int f(int *);  // never reads the parameter, only writes
+int g(int *);  // reads the parameter - expects an initialized variable
 int x, y;
 f(&x);  // okay - only writes to x
 g(&y);  // uses y uninitialized
 \end{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.
+g(&y);  // will use y uninitialized
+\end{cfacode}
+Other languages are able to give errors in the case of uninitialized variable use, but due to backwards compatibility concerns, this cannot be 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.
 …
 };
 struct array_int create_array(int sz) {
   return (struct array_int) { calloc(sizeof(int)*sz) };
+  return (struct array_int) { malloc(sizeof(int)*sz) };
+}
 void destroy_rh(struct resource_holder * rh) {
 …
 In \CFA, a constructor is a function with the name @?{}@.
-Like other operators in \CFA, the name represents the syntax used to call the constructor, e.g., @struct S = { ... };@.
 Every constructor must have a return type of @void@ and at least one parameter, the first of which is colloquially referred to as the \emph{this} parameter, as in many object-oriented programming-languages (however, a programmer can give it an arbitrary name).
 The @this@ parameter must have a pointer type, whose base type is the type of object that the function constructs.
 …
 In C, if the user creates an @Array@ object, the fields @data@ and @len@ are uninitialized, unless an explicit initializer list is present.
 It is the user's responsibility to remember to initialize both of the fields to sensible values, since there are no implicit checks for invalid values or reasonable defaults.
+It is the user's responsibility to remember to initialize both of the fields to sensible values.
 In \CFA, the user can define a constructor to handle initialization of @Array@ objects.
 …
 This constructor initializes @x@ so that its @length@ field has the value 10, and its @data@ field holds a pointer to a block of memory large enough to hold 10 @int@s, and sets the value of each element of the array to 0.
 This particular form of constructor is called the \emph{default constructor}, because it is called on an object defined without an initializer.
 In other words, a default constructor is a constructor that takes a single argument: the @this@ parameter.
+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!^?{}!.
 …
+}
 \end{cfacode}
+The destructor is automatically called at deallocation for all objects of type @Array@.
+Hence, the memory associated with an @Array@ is automatically freed when the object's lifetime ends.
+Since the destructor is automatically called at deallocation for all objects of type @Array@, the memory associated with an @Array@ is automatically freed when the object's lifetime ends.
 The exact guarantees made by \CFA with respect to the calling of destructors are discussed in section \ref{sub:implicit_dtor}.
 …
 \end{cfacode}
 By the previous definition of the default constructor for @Array@, @x@ and @y@ are initialized to valid arrays of length 10 after their respective definitions.
 On line 2, @z@ is initialized with the value of @x@, while on line 3, @y@ is assigned the value of @x@.
+On line 3, @z@ is initialized with the value of @x@, while on line @4@, @y@ is assigned the value of @x@.
 The key distinction between initialization and assignment is that a value to be initialized does not hold any meaningful values, whereas an object to be assigned might.
 In particular, these cases cannot be handled the same way because in the former case @z@ does not currently own an array, while @y@ does.
 …
 The first function is called a \emph{copy constructor}, because it constructs its argument by copying the values from another object of the same type.
 The second function is the standard copy-assignment operator.
 The four functions (default constructor, destructor, copy constructor, and assignment operator) are special in that they safely control the state of most objects.
+These four functions are special in that they control the state of most objects.
 It is possible to define a constructor that takes any combination of parameters to provide additional initialization options.
 …
 Array x, y = { 20, 0xdeadbeef }, z = y;
 \end{cfacode}
 In \CFA, constructor calls look just like C initializers, which allows them to be inserted into legacy C code with minimal code changes, and also provides a very simple syntax that veteran C programmers are familiar with.
 One downside of reusing C initialization syntax is that it isn't possible to determine whether an object is constructed just by looking at its declaration, since that requires knowledge of whether the type is managed at that point.
 …
 Destructors are implicitly called in reverse declaration-order so that objects with dependencies are destructed before the objects they are dependent on.
 \subsection{Calling Syntax}
 \label{sub:syntax}
+\subsection{Syntax}
+\label{sub:syntax} % TODO: finish this section
 There are several ways to construct an object in \CFA.
 As previously introduced, every variable is automatically constructed at its definition, which is the most natural way to construct an object.
 …
 A * y = malloc();  // copy construct: ?{}(&y, malloc())
 ?{}(&x);    // explicit construct x, second construction
 ?{}(y, x);  // explit construct y from x, second construction
 ^?{}(&x);   // explicit destroy x, in different order
+?{}(&x);    // explicit construct x
+?{}(y, x);  // explit construct y from x
+^?{}(&x);   // explicit destroy x
 ^?{}(y);    // explicit destroy y
 …
 // implicit ^?{}(&x);
 \end{cfacode}
 Calling a constructor or destructor directly is a flexible feature that allows complete control over the management of storage.
+Calling a constructor or destructor directly is a flexible feature that allows complete control over the management of a piece of storage.
 In particular, constructors double as a placement syntax.
 \begin{cfacode}
 …
 Finally, constructors and destructors support \emph{operator syntax}.
 Like other operators in \CFA, the function name mirrors the use-case, in that the first $N$ arguments fill in the place of the question mark.
-This syntactic form is similar to the new initialization syntax in \CCeleven, except that it is used in expression contexts, rather than declaration contexts.
 \begin{cfacode}
 struct A { ... };
 …
 Destructor operator syntax is actually an statement, and requires parentheses for symmetry with constructor syntax.
-One of these three syntactic forms should appeal to either C or \CC programmers using \CFA.
 \subsection{Function Generation}
 In \CFA, every type is defined to have the core set of four functions described previously.
 …
 There are several options for user-defined types: structures, unions, and enumerations.
 To aid in ease of use, the standard set of four functions is automatically generated for a user-defined type after its definition is completed.
 By auto-generating these functions, it is ensured that legacy C code continues to work correctly in every context where \CFA expects these functions to exist, since they are generated for every complete type.
+By auto-generating these functions, it is ensured that legacy C code will continue to work correctly in every context where \CFA expects these functions to exist, since they are generated for every complete type.
 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.
+% TODO: examples for enums
 For example, given the enumeration
 \begin{cfacode}
 …
 \end{cfacode}
 In the future, \CFA will introduce strongly-typed enumerations, like those in \CC.
 The existing generated routines are sufficient to express this restriction, since they are currently set up to take in values of that enumeration type.
+The existing generated routines will be sufficient to express this restriction, since they are currently set up to take in values of that enumeration type.
 Changes related to this feature only need to affect the expression resolution phase, where more strict rules will be applied to prevent implicit conversions from integral types to enumeration types, but should continue to permit conversions from enumeration types to @int@.
 In this way, it is still possible to add an @int@ to an enumeration, but the resulting value is an @int@, meaning it cannot be reassigned to an enumeration without a cast.
+In this way, it will still be possible to add an @int@ to an enumeration, but the resulting value will be an @int@, meaning that it won't be possible to reassign the value into an enumeration without a cast.
 For structures, the situation is more complicated.
 Given a structure @S@ with members @M$_0$@, @M$_1$@, ... @M$_{N-1}$@, each function @f@ in the standard set calls \lstinline{f(s->M$_i$, ...)} for each @$i$@.
 That is, a default constructor for @S@ default constructs the members of @S@, the copy constructor copy constructs them, and so on.
 For example, given the structure definition
+For a structure @S@ with members @M$_0$@, @M$_1$@, ... @M$_{N-1}$@, each function @f@ in the standard set calls \lstinline{f(s->M$_i$, ...)} for each @$i$@.
+That is, a default constructor for @S@ default constructs the members of @S@, the copy constructor with copy construct them, and so on.
+For example given the struct definition
 \begin{cfacode}
 struct A {
 …
+}
 \end{cfacode}
 It is important to note that the destructors are called in reverse declaration order to prevent conflicts in the event there are dependencies among members.
+It is important to note that the destructors are called in reverse declaration order to resolve conflicts in the event there are dependencies among members.
 In addition to the standard set, a set of \emph{field constructors} is also generated for structures.
 The field constructors are constructors that consume a prefix of the structure's member-list.
+The field constructors are constructors that consume a prefix of the struct's member list.
 That is, $N$ constructors are built of the form @void ?{}(S *, T$_{\text{M}_0}$)@, @void ?{}(S *, T$_{\text{M}_0}$, T$_{\text{M}_1}$)@, ..., @void ?{}(S *, T$_{\text{M}_0}$, T$_{\text{M}_1}$, ..., T$_{\text{M}_{N-1}}$)@, where members are copy constructed if they have a corresponding positional argument and are default constructed otherwise.
 The addition of field constructors allows structures in \CFA to be used naturally in the same ways as used in C (i.e., to initialize any prefix of the structure), e.g., @A a0 = { b }, a1 = { b, c }@.
+The addition of field constructors allows structs in \CFA to be used naturally in the same ways that they could be used in C (i.e. to initialize any prefix of the struct), e.g., @A a0 = { b }, a1 = { b, c }@.
 Extending the previous example, the following constructors are implicitly generated for @A@.
 \begin{cfacode}
 …
 \end{cfacode}
 For unions, the default constructor and destructor do nothing, as it is not obvious which member, if any, should be constructed.
+For unions, the default constructor and destructor do nothing, as it is not obvious which member if any should be constructed.
 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.
 …
 % This feature works in the \CFA model, since constructors are simply special functions and can be called explicitly, unlike in \CC. % this sentence isn't really true => placement new
 In \CCeleven, unions may have managed members, with the caveat that if there are any members with a user-defined operation, then that operation is not implicitly defined, forcing the user to define the operation if necessary.
+In \CCeleven, this restriction has been loosened to allow unions with managed members, with the caveat that any if there are any members with a user-defined operation, then that operation is not implicitly defined, forcing the user to define the operation if necessary.
 This restriction could easily be added into \CFA once \emph{deleted} functions are added.
 …
 Here, @&s@ and @&s2@ are cast to unqualified pointer types.
 This mechanism allows the same constructors and destructors to be used for qualified objects as for unqualified objects.
+This applies only to implicitly generated constructor calls.
+Hence, explicitly re-initializing qualified objects with a constructor requires an explicit cast.
+As discussed in Section \ref{sub:c_background}, compound literals create unnamed objects.
+This mechanism can continue to be used seamlessly in \CFA with managed types to create temporary objects.
+The object created by a compound literal is constructed using the provided brace-enclosed initializer-list, and is destructed at the end of the scope it is used in.
+For example,
+\begin{cfacode}
+struct A { int x; };
+void ?{}(A *, int, int);
+{
+  int x = (A){ 10, 20 }.x;
+}
+\end{cfacode}
+is equivalent to
+\begin{cfacode}
+struct A { int x, y; };
+void ?{}(A *, int, int);
+{
+  A _tmp;
+  ?{}(&_tmp, 10, 20);
+  int x = _tmp.x;
+  ^?{}(&tmp);
+}
+\end{cfacode}
+Since this applies only to implicitly generated constructor calls, the language does not allow qualified objects to be re-initialized with a constructor without an explicit cast.
 Unlike \CC, \CFA provides an escape hatch that allows a user to decide at an object's definition whether it should be managed or not.
 …
 A a2 @= { 0 };  // unmanaged
 \end{cfacode}
+In this example, @a1@ is a managed object, and thus is default constructed and destructed at the start/end of @a1@'s lifetime, while @a2@ is an unmanaged object and is not implicitly constructed or destructed.
+Instead, @a2->x@ is initialized to @0@ as if it were a C object, because of the explicit initializer.
+In this example, @a1@ is a managed object, and thus is default constructed and destructed at the end of @a1@'s lifetime, while @a2@ is an unmanaged object and is not implicitly constructed or destructed.
+Instead, @a2->x@ is initialized to @0@ as if it were a C object, due to the explicit initializer.
+Existing constructors are ignored when \ateq is used, so that any valid C initializer is able to initialize the object.
 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.
 …
 It is recommended that most objects be managed by sensible constructors and destructors, except where absolutely necessary.
 When a user declares any constructor or destructor, the corresponding intrinsic/generated function and all field constructors for that type are hidden, so that they are not found during expression resolution until the user-defined function goes out of scope.
 Furthermore, if the user declares any constructor, then the intrinsic/generated default constructor is also hidden, precluding default construction.
 These semantics closely mirror the rule for implicit declaration of constructors in \CC, wherein the default constructor is implicitly declared if there is no user-declared constructor \cite[p.~186]{ANSI98:C++}.
+When the user declares any constructor or destructor, the corresponding intrinsic/generated function and all field constructors for that type are hidden, so that they will not be found during expression resolution unless the user-defined function goes out of scope.
+Furthermore, if the user declares any constructor, then the intrinsic/generated default constructor is also hidden, making it so that objects of a type may not be default constructable.
+This closely mirrors the rule for implicit declaration of constructors in \CC, wherein the default constructor is implicitly declared if there is no user-declared constructor. % TODO: cite C++98 page 186??
 \begin{cfacode}
 struct S { int x, y; };
 …
   S s0, s1 = { 0 }, s2 = { 0, 2 }, s3 = s2;  // okay
+  {
     void ?{}(S * s, int i) { s->x = i*2; } // locally hide autogen constructors
+    void ?{}(S * s, int i) { s->x = i*2; }
     S s4;  // error
     S s5 = { 3 };  // okay
 …
 } // 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. % TODO: confirm that this is correct. It might be possible to get subtle errors if you initialize some members then call another constructor... -- in fact, 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).
 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.
 …
 Despite great effort, some forms of C syntax do not work well with constructors in \CFA.
 In particular, constructor calls cannot contain designations (see \ref{sub:c_background}), since this is equivalent to allowing designations on the arguments to arbitrary function calls.
+In C, function prototypes are permitted to have arbitrary parameter names, including no names at all, which may have no connection to the actual names used at function definition.
+Furthermore, a function prototype can be repeated an arbitrary number of times, each time using different names.
 \begin{cfacode}
 // all legal forward declarations in C
 …
 f(b:10, a:20, c:30);  // which parameter is which?
 \end{cfacode}
-In C, function prototypes are permitted to have arbitrary parameter names, including no names at all, which may have no connection to the actual names used at function definition.
-Furthermore, a function prototype can be repeated an arbitrary number of times, each time using different names.
 As a result, it was decided that any attempt to resolve designated function calls with C's function prototype rules would be brittle, and thus it is not sensible to allow designations in constructor calls.
+In addition, constructor calls do not support unnamed nesting.
+\begin{cfacode}
+struct B { int x; };
+struct C { int y; };
+struct A { B b; C c; };
+void ?{}(A *, B);
+void ?{}(A *, C);
+A a = {
+  { 10 },  // construct B? - invalid
+};
+\end{cfacode}
+In C, nesting initializers means that the programmer intends to initialize subobjects 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.
+That is, in the previous example the line marked as an error could mean construct using @?{}(A *, B)@ or with @?{}(A *, C)@, since the inner initializer @{ 10 }@ could be taken as an intermediate object of type @B@ or @C@.
+In practice, however, there could be many objects that can be constructed from a given @int@ (or, indeed, any arbitrary parameter list), and thus a complete solution to this problem would require fully exploring all possibilities.
+More precisely, constructor calls cannot have a nesting depth greater than the number of array components in the type of the initialized object, plus one.
+% Many other languages do allow named arguments, such as Python and Scala, but they do not allow multiple arbitrarily named forward declarations of a function.
+In addition, constructor calls cannot have a nesting depth greater than the number of array components in the type of the initialized object, plus one.
 For example,
 \begin{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.
+In C, having a greater nesting depth means that the programmer intends to initialize subobjects with the nested initializer.
+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.
+That is, in the previous example the line marked as an error could mean construct using @?{}(A *, A, A)@, since the inner initializer @{ 11 }@ could be taken as an intermediate object of type @A@ constructed with @?{}(A *, int)@.
+In practice, however, there could be many objects that can be constructed from a given @int@ (or, indeed, any arbitrary parameter list), and thus a complete solution to this problem would require fully exploring all possibilities.
 It should be noted that unmanaged objects can still make use of designations and nested initializers in \CFA.
-It is simple to overcome this limitation for managed objects by making use of compound literals, so that the arguments to the constructor call are explicitly typed.
 \subsection{Implicit Destructors}
 …
 \end{cfacode}
+%% having this feels excessive, but it's here if necessary
+% This procedure generates the following code.
+% \begin{cfacode}
+% void f(int i){
+%   struct A x;
+%   ?{}(&x);
+%   {
+%     struct A y;
+%     ?{}(&y);
+%     {
+%       struct A z;
+%       ?{}(&z);
+%       {
+%         if ((i==0)!=0) {
+%           ^?{}(&z);
+%           ^?{}(&y);
+%           ^?{}(&x);
+%           return;
+%         }
+%       }
+%       if (((i==1)!=0) {
+%           ^?{}(&z);
+%           ^?{}(&y);
+%           ^?{}(&x);
+%           return ;
+%       }
+%       ^?{}(&z);
+%     }
+%     if ((i==2)!=0) {
+%       ^?{}(&y);
+%       ^?{}(&x);
+%       return;
+%     }
+%     ^?{}(&y);
+%   }
+%   ^?{}(&x);
+% }
+% \end{cfacode}
 The next example illustrates the use of simple continue and break statements and the manner that they interact with implicit destructors.
 \begin{cfacode}
 …
 \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.
+In the case where @i@ is @2@, the continue statement runs the loop update expression and attemps 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.
 When @i@ is @3@, the break statement moves control to just past the end of the loop.
 …
 L1: for (int i = 0; i < 10; i++) {
   A x;
   for (int j = 0; j < 10; j++) {
+  L2: for (int j = 0; j < 10; j++) {
     A y;
+    if (i == 1) {
+    if (j == 0) {
+      continue;    // destruct y
+    } else if (j == 1) {
+      break;       // destruct y
+    } else if (i == 1) {
       continue L1; // destruct y
     } else if (i == 2) {
 …
 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.
 …
 Exempt from these rules are intrinsic and builtin 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.
 This is an important detail to bear in mind when using unmanaged objects, and could produce unexpected results when mixed with objects that are explicitly constructed.
 \begin{cfacode}
 …
 void ^?{}(A *);
 A identity(A x) { // pass by value => need local copy
   return x;       // return by value => make call-site copy
+A f(A x) {
+  return x;
+}
 A y, z @= {};
 identity(y);  // copy construct y into x
 identity(z);  // copy construct z into x
+identity(y);
+identity(z);
 \end{cfacode}
 Note that @z@ is copy constructed into a temporary variable to be passed as an argument, which is also destructed after the call.
+A special syntactic form, such as a variant of \ateq, could be implemented to specify at the call site that an argument should not be copy constructed, to regain some control for the C programmer.
 This generates the following
 \begin{cfacode}
 struct A f(struct A x){
   struct A _retval_f;    // return value
   ?{}((&_retval_f), x);  // copy construct return value
+  struct A _retval_f;
+  ?{}((&_retval_f), x);
   return _retval_f;
+}
 struct A y;
+?{}(&y);                 // default construct
+struct A z = { 0 };      // C default
+struct A _tmp_cp1;       // argument 1
+struct A _tmp_cp_ret0;   // return value
+_tmp_cp_ret0=f(
+  (?{}(&_tmp_cp1, y) , _tmp_cp1)  // argument is a comma expression
+), _tmp_cp_ret0;         // return value for cascading
+^?{}(&_tmp_cp_ret0);     // destruct return value
+^?{}(&_tmp_cp1);         // destruct argument 1
+struct A _tmp_cp2;       // argument 1
+struct A _tmp_cp_ret1;   // return value
+_tmp_cp_ret1=f(
+  (?{}(&_tmp_cp2, z), _tmp_cp2)  // argument is a common expression
+), _tmp_cp_ret1;         // return value for cascading
+^?{}(&_tmp_cp_ret1);     // destruct return value
+^?{}(&_tmp_cp2);         // destruct argument 1
+?{}(&y);
+struct A z = { 0 };
+struct A _tmp_cp1;     // argument 1
+struct A _tmp_cp_ret0; // return value
+_tmp_cp_ret0=f((?{}(&_tmp_cp1, y) , _tmp_cp1)), _tmp_cp_ret0;
+^?{}(&_tmp_cp_ret0);   // return value
+^?{}(&_tmp_cp1);       // argument 1
+struct A _tmp_cp2;     // argument 1
+struct A _tmp_cp_ret1; // return value
+_tmp_cp_ret1=f((?{}(&_tmp_cp2, z), _tmp_cp2)), _tmp_cp_ret1;
+^?{}(&_tmp_cp_ret1);   // return value
+^?{}(&_tmp_cp2);       // argument 1
 ^?{}(&y);
 \end{cfacode}
-A special syntactic form, such as a variant of \ateq, can be implemented to specify at the call site that an argument should not be copy constructed, to regain some control for the C programmer.
-\begin{cfacode}
-identity(z@);  // do not copy construct argument
-               // - will copy construct/destruct return value
-A@ identity_nocopy(A @ x) {  // argument not copy constructed or destructed
-  return x;  // not copy constructed
-             // return type marked @ => not destructed
+}
-\end{cfacode}
-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.
 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.
+It is currently the case that constructors and destructors which use the @this@ pointer as a unique identifier to store data externally will not work correctly for return value objects.
+Thus is it not safe to rely on an object's @this@ pointer to remain constant throughout execution of the program.
 \begin{cfacode}
 A * external_data[32];
 …
+  }
+}
-A makeA() {
-  A x;  // stores &x in external_data
-  return x;
+}
-makeA();  // return temporary has a different address than x
-// equivalent to:
-//   A _tmp;
-//   _tmp = makeA(), _tmp;
-//   ^?{}(&_tmp);
 \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.
 This problem could be solved in the translator by changing the function signatures so that the return value is moved into the parameter list.
+Due to copying on return, the current object being destructed will not exist in the array if an @A@ object is ever returned by value from a function.
+This problem could be solved in the translator by mutating the function signatures so that the return value is moved into the parameter list.
 For example, the translator could restructure the code like so
 \begin{cfacode}
 …
 \end{cfacode}
 This transformation provides @f@ with the address of the return variable so that it can be constructed into directly.
 It is worth pointing out that this kind of signature rewriting already occurs in polymorphic functions that return by value, as discussed in \cite{Bilson03}.
+It is worth pointing out that this kind of signature rewriting already occurs in polymorphic functions which return by value, as discussed in \cite{Bilson03}.
 A key difference in this case is that every function would need to be rewritten like this, since types can switch between managed and unmanaged at different scope levels, e.g.
 \begin{cfacode}
 struct A { int v; };
 A x; // unmanaged, since only trivial constructors are available
+A x; // unmanaged
+{
   void ?{}(A * a) { ... }
 …
 A z; // unmanaged
 \end{cfacode}
 Hence there is not enough information to determine at function declaration whether a type is managed or not, and thus it is the case that all signatures have to be rewritten to account for possible copy constructor and destructor calls.
+Hence there is not enough information to determine at function declaration to determine whether a type is managed or not, and thus it is the case that all signatures have to be rewritten to account for possible copy constructor and destructor calls.
 Even with this change, it would still be possible to declare backwards compatible function prototypes with an @extern "C"@ block, which allows for the definition of C-compatible functions within \CFA code, however this would require actual changes to the way code inside of an @extern "C"@ function is generated as compared with normal code generation.
 Furthermore, it is not possible to overload C functions, so using @extern "C"@ to declare functions is of limited use.
 It would be possible to regain some control by adding an attribute to structs that specifies whether they can be managed or not (perhaps \emph{manageable} or \emph{unmanageable}), and to emit an error in the case that a constructor or destructor is declared for an unmanageable type.
+Furthermore, it isn't possible to overload C functions, so using @extern "C"@ to declare functions is of limited use.
+It would be possible to regain some control by adding an attribute to structs which specifies whether they can be managed or not (perhaps \emph{manageable} or \emph{unmanageable}), and to emit an error in the case that a constructor or destructor is declared for an unmanageable type.
 Ideally, structs should be manageable by default, since otherwise the default case becomes more verbose.
 This means that in general, function signatures would have to be rewritten, and in a select few cases the signatures would not be rewritten.
 …
 \section{Implementation}
 \subsection{Array Initialization}
 Arrays are a special case in the C type-system.
+Arrays are a special case in the C type system.
 C arrays do not carry around their size, making it impossible to write a standalone \CFA function that constructs or destructs an array while maintaining the standard interface for constructors and destructors.
 Instead, \CFA defines the initialization and destruction of an array recursively.
 …
 By default, objects within a translation unit are constructed in declaration order, and destructed in the reverse order.
 The default order of construction of objects amongst translation units is unspecified.
+% TODO: not yet implemented, but g++ provides attribute init_priority, which allows specifying the order of global construction on a per object basis
+%   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
 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: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
 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.
 …
 \end{cfacode}
-%   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.
-A similar attribute can be implemented in \CFA by pulling marked objects into global constructor/destructor-attribute functions with the specified priority.
-For example,
-\begin{cfacode}
-struct A { ... };
-void ?{}(A *, int);
-void ^?{}(A *);
-__attribute__((init_priority(200))) A x = { 123 };
-\end{cfacode}
-would generate
-\begin{cfacode}
-A x;
-__attribute__((constructor(200))) __init_x() {
-  ?{}(&x, 123);  // construct x with priority 200
+}
-__attribute__((destructor(200))) __destroy_x() {
-  ?{}(&x);       // destruct x with priority 200
+}
-\end{cfacode}
 \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??
 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.
+Much like global variables, in C @static@ variables must be initialized to a \emph{compile-time constant value} so that a compiler is able to create storage for the variable and initialize it before the program begins running.
 Yet again, this rule is too restrictive for a language with constructors and destructors.
 …
 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@, and the companion @bool@'s value is set so that subsequent invocations of the function will 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.
 …
 \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@.
+The significance of constructors as expressions rather than as statements is that the result of a constructor expression can be used as part of a larger expression.
+A key example is the use of constructor expressions to initialize the result of a call to standard C routine @malloc@.
 \begin{cfacode}
 struct X { ... };

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

Context Navigation

Changes in doc/rob_thesis/ctordtor.tex [7493339:93afb96]

Legend:

doc/rob_thesis/ctordtor.tex

Download in other formats: