Changes in doc/rob_thesis/ctordtor.tex [93afb96:f92aa32]
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/rob_thesis/ctordtor.tex
r93afb96 rf92aa32 3 3 %====================================================================== 4 4 5 % TODO: discuss move semantics; they haven't been implemented, but could be. Currently looking at alternative models. (future work) 6 7 % TODO: as an experiment, implement Andrei Alexandrescu's ScopeGuard http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758?pgno=2 5 % 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 8 6 % doesn't seem possible to do this without allowing ttype on generic structs? 9 7 10 % If a Cforall constructor is in scope, C style initialization is11 % disabled by default.12 % * initialization rule: if any constructor is in scope for type T, try13 % to find a matching constructor for the call. If there are no14 % constructors in scope for type T, then attempt to fall back on15 % C-style initialization.16 % + if this rule was not in place, it would be easy to accidentally17 % use C-style initialization in certain cases, which could lead to18 % subtle errors [2]19 % - this means we need special syntax if we want to allow users to force20 % a C-style initialization (to give users more control)21 % - two different declarations in the same scope can be implicitly22 % initialized differently. That is, there may be two objects of type23 % T that are initialized differently because there is a constructor24 % definition between them. This is not technically specific to25 % constructors.26 27 % C-style initializers can be accessed with @= syntax28 % + provides a way to get around the requirement of using a constructor29 % (for advanced programmers only)30 % - can break invariants in the type => unsafe31 % * provides a way of asserting that a variable is an instance of a32 % C struct (i.e. a POD struct), and so will not be implicitly33 % destructed (this can be useful at times, maybe mitigates the need34 % for move semantics?) [3]35 % + can modernize a code base one step at a time36 37 % Cforall constructors can be used in expressions to initialize any38 % piece of memory.39 % + malloc() { ... } calls the appropriate constructor on the newly40 % allocated space; the argument is moved into the constructor call41 % without taking its address [4]42 % - with the above form, there is still no way to ensure that43 % dynamically allocated objects are constructed. To resolve this,44 % we might want a stronger "new" function which always calls the45 % constructor, although how we accomplish that is currently still46 % unresolved (compiler magic vs. better variadic functions?)47 % + This can be used as a placement syntax [5]48 % - can call the constructor on an object more than once, which could49 % cause resource leaks and reinitialize const fields (can try to50 % detect and prevent this in some cases)51 % * compiler always tries to implicitly insert a ctor/dtor pair for52 % non-@= objects.53 % * For POD objects, this will resolve to an autogenerated or54 % intrinsic function.55 % * Intrinsic functions are not automatically called. Autogenerated56 % are, because they may call a non-autogenerated function.57 % * destructors are automatically inserted at appropriate branches58 % (e.g. return, break, continue, goto) and at the end of the block59 % in which they are declared.60 % * For @= objects, the compiler never tries to interfere and insert61 % constructor and destructor calls for that object. Copy constructor62 % calls do not count, because the object is not the target of the copy63 % constructor.64 65 % A constructor is declared with the name ?{}66 % + combines the look of C initializers with the precedent of ?() being67 % the name for the function call operator68 % + it is possible to easily search for all constructors in a project69 % and immediately know that a function is a constructor by seeing the70 % name "?{}"71 72 % A destructor is declared with the name ^?{}73 % + name mirrors a constructor's name, with an extra symbol to74 % distinguish it75 % - the symbol '~' cannot be used due to parsing conflicts with the76 % unary '~' (bitwise negation) operator - this conflict exists because77 % we want to allow users to write ^x{}; to destruct x, rather than78 % ^?{}(&x);79 80 % The first argument of a constructor must be a pointer. The constructed81 % type is the base type of the pointer. E.g. void ?{}(T *) is a default82 % constructor for a T.83 % + can name the argument whatever you like, so not constrained by84 % language keyword "this" or "self", etc.85 % - have to explicitly qualify all object members to initialize them86 % (e.g. this->x = 0, rather than just x = 0)87 88 % Destructors can take arguments other than just the destructed pointer89 % * open research problem: not sure how useful this is90 91 % Pointer constructors92 % + can construct separately compiled objects (opaque types) [6]93 % + orthogonal design, follows directly from the definition of the first94 % argument of a constructor95 % - may require copy constructor or move constructor (or equivalent)96 % for correct implementation, which may not be obvious to everyone97 % + required feature for the prelude to specify as much behavior as possible98 % (similar to pointer assignment operators in this respect)99 100 % Designations can only be used for C-style initialization101 % * designation for constructors is equivalent to designation for any102 % general function call. Since a function prototype can be redeclared103 % many times, with arguments named differently each time (or not at104 % all!), this is considered to be an undesirable feature. We could105 % construct some set of rules to allow this behaviour, but it is106 % probably more trouble than it's worth, and no matter what we choose,107 % it is not likely to be obvious to most people.108 109 % Constructing an anonymous member [7]110 % + same as with calling any other function on an anonymous member111 % (implicit conversion by the compiler)112 % - may be some cases where this is ambiguous => clarify with a cast113 % (try to design APIs to avoid sharing function signatures between114 % composed types to avoid this)115 116 % Default Constructors and Destructors are called implicitly117 % + cannot forget to construct or destruct an object118 % - requires special syntax to specify that an object is not to be119 % constructed (@=)120 % * an object will not be implicitly constructed OR destructed if121 % explicitly initialized like a C object (@= syntax)122 % * an object will be destructed if there are no constructors in scope123 % (even though it is initialized like a C object) [8]124 125 % An object which changes from POD type to non POD type will not change126 % the semantics of a type containing it by composition127 % * That is, constructors will not be regenerated at the point where128 % an object changes from POD type to non POD type, because this could129 % cause a cascade of constructors being regenerated for many other130 % types. Further, there is precedence for this behaviour in other131 % facets of Cforall's design, such as how nested functions interact.132 % * This behaviour can be simplified in a language without declaration133 % before use, because a type can be classified as POD or non POD134 % (rather than potentially changing between the two at some point) at135 % at the global scope (which is likely the most common case)136 % * [9]137 138 % Changes to polymorphic type classes139 % * dtype and ftype remain the same140 % * forall(otype T) is currently essentially the same as141 % forall(dtype T | { @size(T); void ?=?(T *, T); }).142 % The big addition is that you can declare an object of type T, rather143 % than just a pointer to an object of type T since you know the size,144 % and you can assign into a T.145 % * this definition is changed to add default constructor and146 % destructor declarations, to remain consistent with what type meant147 % before the introduction of constructors and destructors.148 % * that is, forall(type T) is now essentially the same as149 % forall(dtype T | { @size(T); void ?=?(T *, T);150 % void ?{}(T *); void ^?{}(T *); })151 % + this is required to make generic types work correctly in152 % polymorphic functions153 % ? since declaring a constructor invalidates the autogenerated154 % routines, it is possible for a type to have constructors, but155 % not default constructors. That is, it might be the case that156 % you want to write a polymorphic function for a type which has157 % a size, but non-default constructors? Some options:158 % * declaring a constructor as a part of the assertions list for159 % a type declaration invalidates the default, so160 % forall(otype T | { void ?{}(T *, int); })161 % really means162 % forall(dtype T | { @size(T); void ?=?(T *, T);163 % void ?{}(T *, int); void ^?{}(T *); })164 % * force users to fully declare the assertions list like the165 % above in this case (this seems very undesirable)166 % * add another type class with the current desugaring of type167 % (just size and assignment)168 % * provide some way of subtracting from an existing assertions169 % list (this might be useful to have in general)170 171 % Implementation issues:172 % Changes to prelude/autogen or built in defaults?173 % * pointer ctors/dtors [prelude]174 % * other pointer type routines are declared in the prelude, and this175 % doesn't seem like it should be any different176 % * basic type ctors/dtors [prelude]177 % * other basic type routines are declared in the prelude, and this178 % doesn't seem like it should be any different179 % ? aggregate types [undecided, but leaning towards autogenerate]180 % * prelude181 % * routines specific to aggregate types cannot be predeclared in182 % the prelude because we don't know the name of every183 % aggregate type in the entire program184 % * autogenerate185 % + default assignment operator is already autogenerated for186 % aggregate types187 % * this seems to lead us in the direction of autogenerating,188 % because we may have a struct which contains other objects189 % that require construction [10]. If we choose not to190 % autogenerate in this case, then objects which are part of191 % other objects by composition will not be constructed unless192 % a constructor for the outer type is explicitly defined193 % * in this case, we would always autogenerate the appropriate194 % constructor(s) for an aggregate type, but just like with195 % basic types, pointer types, and enum types, the constructor196 % call can be elided when when it is not necessary.197 % + constructors will have to be explicitly autogenerated198 % in the case where they are required for a polymorphic function,199 % when no user defined constructor is in scope, which may make it200 % easiest to always autogenerate all appropriate constructors201 % - n+2 constructors would have to be generated for a POD type202 % * one constructor for each number of valid arguments [0, n],203 % plus the copy constructor204 % * this is taking a simplified approach: in C, it is possible205 % to omit the enclosing braces in a declaration, which would206 % lead to a combinatorial explosion of generated constructors.207 % In the interest of keeping things tractable, Cforall may be208 % incompatible with C in this case. [11]209 % * for non-POD types, only autogenerate the default and copy210 % constructors211 % * alternative: generate only the default constructor and212 % special case initialization for any other constructor when213 % only the autogenerated one exists214 % - this is not very sensible, as by the previous point, these215 % constructors may be needed for polymorphic functions216 % anyway.217 % - must somehow distinguish in resolver between autogenerated and218 % user defined constructors (autogenerated should never be chosen219 % when a user defined option exists [check first parameter], even220 % if full signature differs) (this may also have applications221 % to other autogenerated routines?)222 % - this scheme does not naturally support designation (i.e. general223 % functions calls do not support designation), thus these cases224 % will have to be treated specially in either case225 % * defaults226 % * i.e. hardcode a new set of rules for some "appropriate" default227 % behaviour for228 % + when resolving an initialization expression, explicitly check to229 % see if any constructors are in scope. If yes, attempt to resolve230 % to a constructor, and produce an error message if a match is not231 % found. If there are no constructors in scope, resolve to232 % initializing each field individually (C-style)233 % + does not attempt to autogenerate constructors for POD types,234 % which can be seen as a space optimization for the program235 % binary236 % - as stated previously, a polymorphic routine may require these237 % autogenerated constructors, so this doesn't seem like a big win,238 % because this leads to more complicated logic and tracking of239 % which constructors have already been generated240 % - even though a constructor is not explicitly declared or used241 % polymorphically, we might still need one for all uses of a242 % struct (e.g. in the case of composition).243 % * the biggest tradeoff in autogenerating vs. defaulting appears to244 % be in where and how the special code to check if constructors are245 % present is handled. It appears that there are more reasons to246 % autogenerate than not.247 248 % --- examples249 % [1] As an example of using constructors polymorphically, consider a250 % slight modification on the foldl example I put on the mailing list a251 % few months ago:252 253 % context iterable(type collection, type element, type iterator) {254 % void ?{}(iterator *, collection); // used to be makeIterator, but can255 % // idiomatically use constructor256 % int hasNext(iterator);257 % iterator ++?(iterator *);258 % lvalue element *?(iterator);259 % };260 261 262 % forall(type collection, type element, type result, type iterator263 % | iterable(collection, element, iterator))264 % result foldl(collection c, result acc,265 % result (*reduce)(result, element)) {266 % iterator it = { c };267 % while (hasNext(it)) {268 % acc = reduce(acc, *it);269 % ++it;270 % }271 % return acc;272 % }273 274 % Now foldl makes use of the knowledge that the iterator type has a275 % single argument constructor which takes the collection to iterate276 % over. This pattern allows polymorphic code to look more natural277 % (constructors are generally preferred to named initializer/creation278 % routines, e.g. "makeIterator")279 280 % [2] An example of some potentially dangerous code that we don't want281 % to let easily slip through the cracks - if this is really what you282 % want, then use @= syntax for the second declaration to quiet the283 % compiler.284 285 % struct A { int x, y, z; }286 % ?{}(A *, int);287 % ?{}(A *, int, int, int);288 289 % A a1 = { 1 }; // uses ?{}(A *, int);290 % A a2 = { 2, 3 }; // C-style initialization -> no invariants!291 % A a3 = { 4, 5, 6 }; // uses ?{}(A *, int, int, int);292 293 % [3] Since @= syntax creates a C object (essentially a POD, as far as294 % the compiler is concerned), the object will not be destructed295 % implicitly when it leaves scope, nor will it be copy constructed when296 % it is returned. In this case, a memcpy should be equivalent to a move.297 298 % // Box.h299 % struct Box;300 % void ?{}(Box **, int};301 % void ^?{}(Box **);302 % Box * make_fortytwo();303 304 % // Box.cfa305 % Box * make_fortytwo() {306 % Box *b @= {};307 % (&b){ 42 }; // construct explicitly308 % return b; // no destruction, essentially a move?309 % }310 311 % [4] Cforall's typesafe malloc can be composed with constructor312 % expressions. It is possible for a user to define their own functions313 % similar to malloc and achieve the same effects (e.g. Aaron's example314 % of an arena allocator)315 316 % // CFA malloc317 % forall(type T)318 % T * malloc() { return (T *)malloc(sizeof(T)); }319 320 % struct A { int x, y, z; };321 % void ?{}(A *, int);322 323 % int foo(){324 % ...325 % // desugars to:326 % // A * a = ?{}(malloc(), 123);327 % A * a = malloc() { 123 };328 % ...329 % }330 331 % [5] Aaron's example of combining function calls with constructor332 % syntax to perform an operation similar to C++'s std::vector::emplace333 % (i.e. to construct a new element in place, without the need to334 % copy)335 336 % forall(type T)337 % struct vector {338 % T * elem;339 % int len;340 % ...341 % };342 343 % ...344 % forall(type T)345 % T * vector_new(vector(T) * v) {346 % // reallocate if needed347 % return &v->elem[len++];348 % }349 350 % int main() {351 % vector(int) * v = ...352 % vector_new(v){ 42 }; // add element to the end of vector353 % }354 355 % [6] Pointer Constructors. It could be useful to use the existing356 % constructor syntax even more uniformly for ADTs. With this, ADTs can357 % be initialized in the same manor as any other object in a polymorphic358 % function.359 360 % // vector.h361 % forall(type T) struct vector;362 % forall(type T) void ?{}(vector(T) **);363 % // adds an element to the end364 % forall(type T) vector(T) * ?+?(vector(T) *, T);365 366 % // vector.cfa367 % // don't want to expose the implementation to the user and/or don't368 % // want to recompile the entire program if the struct definition369 % // changes370 371 % forall(type T) struct vector {372 % T * elem;373 % int len;374 % int capacity;375 % };376 377 % forall(type T) void resize(vector(T) ** v) { ... }378 379 % forall(type T) void ?{}(vector(T) ** v) {380 % vector(T) * vect = *v = malloc();381 % vect->capacity = 10;382 % vect->len = 0;383 % vect->elem = malloc(vect->capacity);384 % }385 386 % forall(type T) vector(T) * ?+?(vector(T) *v, T elem) {387 % if (v->len == v->capacity) resize(&v);388 % v->elem[v->len++] = elem;389 % }390 391 % // main.cfa392 % #include "adt.h"393 % forall(type T | { T ?+?(T, int); }394 % T sumRange(int lower, int upper) {395 % T x; // default construct396 % for (int i = lower; i <= upper; i++) {397 % x = x + i;398 % }399 % return x;400 % }401 402 % int main() {403 % vector(int) * numbers = sumRange(1, 10);404 % // numbers is now a vector containing [1..10]405 406 % int sum = sumRange(1, 10);407 % // sum is now an int containing the value 55408 % }409 410 % [7] The current proposal is to use the plan 9 model of inheritance.411 % Under this model, all of the members of an unnamed struct instance412 % become members of the containing struct. In addition, an object413 % can be passed as an argument to a function expecting one of its414 % base structs.415 416 % struct Point {417 % double x;418 % double y;419 % };420 421 % struct ColoredPoint {422 % Point; // anonymous member (no identifier)423 % // => a ColoredPoint has an x and y of type double424 % int color;425 % };426 427 % ColoredPoint cp = ...;428 % cp.x = 10.3; // x from Point is accessed directly429 % cp.color = 0x33aaff; // color is accessed normally430 % foo(cp); // cp can be used directly as a Point431 432 % void ?{}(Point *p, double x, double y) {433 % p->x = x;434 % p->y = y;435 % }436 437 % void ?{}(ColoredPoint *cp, double x, double y, int color) {438 % (&cp){ x, y }; // unambiguous, no ?{}(ColoredPoint*,double,double)439 % cp->color = color;440 % }441 442 % struct Size {443 % double width;444 % double height;445 % };446 447 % void ?{}(Size *s, double w, double h) {448 % p->width = w;449 % p->height = h;450 % }451 452 % struct Foo {453 % Point;454 % Size;455 % }456 457 % ?{}(Foo &f, double x, double y, double w, double h) {458 % // (&F,x,y) is ambiguous => is it ?{}(Point*,double,double) or459 % // ?{}(Size*,double,double)? Solve with a cast:460 % ((Point*)&F){ x, y };461 % ((Size*)&F){ w, h };462 % }463 464 % [8] Destructors will be called on objects that were not constructed.465 466 % struct A { ... };467 % ^?{}(A *);468 % {469 % A x;470 % A y @= {};471 % } // x is destructed, even though it wasn't constructed472 % // y is not destructed, because it is explicitly a C object473 474 475 % [9] A type's constructor is generated at declaration time using476 % current information about an object's members. This is analogous to477 % the treatment of other operators. For example, an object's assignment478 % operator will not change to call the override of a member's assignment479 % operator unless the object's assignment is also explicitly overridden.480 % This problem can potentially be treated differently in Do, since each481 % compilation unit is passed over at least twice (once to gather482 % symbol information, once to generate code - this is necessary to483 % achieve the "No declarations" goal)484 485 % struct A { ... };486 % struct B { A x; };487 % ...488 % void ?{}(A *); // from this point on, A objects will be constructed489 % B b1; // b1 and b1.x are both NOT constructed, because B490 % // objects are not constructed491 % void ?{}(B *); // from this point on, B objects will be constructed492 % B b2; // b2 and b2.x are both constructed493 494 % struct C { A x; };495 % // implicit definition of ?{}(C*), because C is not a POD type since496 % // it contains a non-POD type by composition497 % C c; // c and c.x are both constructed498 499 % [10] Requiring construction by composition500 501 % struct A {502 % ...503 % };504 505 % // declared ctor disables default c-style initialization of506 % // A objects; A is no longer a POD type507 % void ?{}(A *);508 509 % struct B {510 % A x;511 % };512 513 % // B objects can not be C-style initialized, because A objects514 % // must be constructed => B objects are transitively not POD types515 % B b; // b.x must be constructed, but B is not constructible516 % // => must autogenerate ?{}(B *) after struct B definition,517 % // which calls ?{}(&b.x)518 519 % [11] Explosion in the number of generated constructors, due to strange520 % C semantics.521 522 % struct A { int x, y; };523 % struct B { A u, v, w; };524 525 % A a = { 0, 0 };526 527 % // in C, you are allowed to do this528 % B b1 = { 1, 2, 3, 4, 5, 6 };529 % B b2 = { 1, 2, 3 };530 % B b3 = { a, a, a };531 % B b4 = { a, 5, 4, a };532 % B b5 = { 1, 2, a, 3 };533 534 % // we want to disallow b1, b2, b4, and b5 in Cforall.535 % // In particular, we will autogenerate these constructors:536 % void ?{}(A *); // default/0 parameters537 % void ?{}(A *, int); // 1 parameter538 % void ?{}(A *, int, int); // 2 parameters539 % void ?{}(A *, const A *); // copy constructor540 541 % void ?{}(B *); // default/0 parameters542 % void ?{}(B *, A); // 1 parameter543 % void ?{}(B *, A, A); // 2 parameters544 % void ?{}(B *, A, A, A); // 3 parameters545 % void ?{}(B *, const B *); // copy constructor546 547 % // we will not generate constructors for every valid combination548 % // of members in C. For example, we will not generate549 % void ?{}(B *, int, int, int, int, int, int); // b1 would need this550 % void ?{}(B *, int, int, int); // b2 would need this551 % void ?{}(B *, A, int, int, A); // b4 would need this552 % void ?{}(B *, int, int, A, int); // b5 would need this553 % // and so on554 555 556 557 % TODO: talk somewhere about compound literals?558 559 8 Since \CFA is a true systems language, it does not provide a garbage collector. 560 As well, \CFA is not an object-oriented programming language, i.e. structures cannot have routine members.9 As well, \CFA is not an object-oriented programming language, i.e., structures cannot have routine members. 561 10 Nevertheless, one important goal is to reduce programming complexity and increase safety. 562 11 To that end, \CFA provides support for implicit pre/post-execution of routines for objects, via constructors and destructors. 563 12 564 % TODO: this is old. remove or refactor565 % Manual resource management is difficult.566 % Part of the difficulty results from not having any guarantees about the current state of an object.567 % 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.568 569 % 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.570 % 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.571 % Constructors and destructors can help to simplify resource management when used in a disciplined way.572 % In particular, when all resources are acquired in a constructor, and all resources are released in a destructor, no resource leaks are possible.573 % This pattern is a popular idiom in several languages, such as \CC, known as RAII (Resource Acquisition Is Initialization).574 575 13 This chapter details the design of constructors and destructors in \CFA, along with their current implementation in the translator. 576 Generated code samples have been edited to provide comments for clarity and to save on space.14 Generated code samples have been edited for clarity and brevity. 577 15 578 16 \section{Design Criteria} … … 592 30 Next, @x@ is assigned the value of @y@. 593 31 In the last line, @z@ is implicitly initialized to 0 since it is marked @static@. 594 The key difference between assignment and initialization being that assignment occurs on a live object (i.e. an object that contains data).32 The key difference between assignment and initialization being that assignment occurs on a live object (i.e., an object that contains data). 595 33 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. 596 Use of uninitialized variables yields undefined behaviour, which is a common source of errors in C programs. % TODO: *citation* 597 598 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. 599 Many C compilers give good warnings most of the time, but they cannot in all cases. 600 \begin{cfacode} 601 int f(int *); // never reads the parameter, only writes 602 int g(int *); // reads the parameter - expects an initialized variable 34 Use of uninitialized variables yields undefined behaviour, which is a common source of errors in C programs. 35 36 Initialization of a declaration is strictly optional, permitting uninitialized variables to exist. 37 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. 38 Many C compilers give good warnings for uninitialized variables most of the time, but they cannot in all cases. 39 \begin{cfacode} 40 int f(int *); // output parameter: never reads, only writes 41 int g(int *); // input parameter: never writes, only reads, 42 // so requires initialized variable 603 43 604 44 int x, y; 605 45 f(&x); // okay - only writes to x 606 g(&y); // will usey uninitialized607 \end{cfacode} 608 Other languages are able to give errors in the case of uninitialized variable use, but due to backwards compatibility concerns, this cannot bethe case in \CFA.609 610 In C, constructors and destructors are often mimicked by providing routines that create and tear down objects, where the teardown function is typically only necessary if the type modifies the execution environment.46 g(&y); // uses y uninitialized 47 \end{cfacode} 48 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. 49 50 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. 611 51 \begin{cfacode} 612 52 struct array_int { … … 614 54 }; 615 55 struct array_int create_array(int sz) { 616 return (struct array_int) { malloc(sizeof(int)*sz) };56 return (struct array_int) { calloc(sizeof(int)*sz) }; 617 57 } 618 58 void destroy_rh(struct resource_holder * rh) { … … 634 74 Furthermore, even with this idiom it is easy to make mistakes, such as forgetting to destroy an object or destroying it multiple times. 635 75 636 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.76 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. 637 77 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. 638 78 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. 639 79 640 80 In \CFA, a constructor is a function with the name @?{}@. 81 Like other operators in \CFA, the name represents the syntax used to call the constructor, e.g., @struct S = { ... };@. 641 82 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). 642 83 The @this@ parameter must have a pointer type, whose base type is the type of object that the function constructs. … … 655 96 656 97 In C, if the user creates an @Array@ object, the fields @data@ and @len@ are uninitialized, unless an explicit initializer list is present. 657 It is the user's responsibility to remember to initialize both of the fields to sensible values .98 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. 658 99 In \CFA, the user can define a constructor to handle initialization of @Array@ objects. 659 100 … … 671 112 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. 672 113 This particular form of constructor is called the \emph{default constructor}, because it is called on an object defined without an initializer. 673 In other words, a default constructor is a constructor that takes a single argument ,the @this@ parameter.674 675 In \CFA, a destructor is a function much like a constructor, except that its name is \lstinline!^?{}! .114 In other words, a default constructor is a constructor that takes a single argument: the @this@ parameter. 115 116 In \CFA, a destructor is a function much like a constructor, except that its name is \lstinline!^?{}! and it take only one argument. 676 117 A destructor for the @Array@ type can be defined as such. 677 118 \begin{cfacode} … … 680 121 } 681 122 \end{cfacode} 682 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. 123 The destructor is automatically called at deallocation for all objects of type @Array@. 124 Hence, the memory associated with an @Array@ is automatically freed when the object's lifetime ends. 683 125 The exact guarantees made by \CFA with respect to the calling of destructors are discussed in section \ref{sub:implicit_dtor}. 684 126 … … 691 133 \end{cfacode} 692 134 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. 693 On line 3, @z@ is initialized with the value of @x@, while on line @4@, @y@ is assigned the value of @x@.135 On line 2, @z@ is initialized with the value of @x@, while on line 3, @y@ is assigned the value of @x@. 694 136 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. 695 137 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. … … 712 154 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. 713 155 The second function is the standard copy-assignment operator. 714 The se four functions are special in that they control the state of most objects.156 The four functions (default constructor, destructor, copy constructor, and assignment operator) are special in that they safely control the state of most objects. 715 157 716 158 It is possible to define a constructor that takes any combination of parameters to provide additional initialization options. 717 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.159 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. 718 160 \begin{cfacode} 719 161 void ?{}(Array * arr, int capacity, int fill) { … … 729 171 Array x, y = { 20, 0xdeadbeef }, z = y; 730 172 \end{cfacode} 173 731 174 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. 732 175 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. … … 748 191 Destructors are implicitly called in reverse declaration-order so that objects with dependencies are destructed before the objects they are dependent on. 749 192 750 \subsection{ Syntax}751 \label{sub:syntax} % TODO: finish this section193 \subsection{Calling Syntax} 194 \label{sub:syntax} 752 195 There are several ways to construct an object in \CFA. 753 196 As previously introduced, every variable is automatically constructed at its definition, which is the most natural way to construct an object. … … 773 216 A * y = malloc(); // copy construct: ?{}(&y, malloc()) 774 217 775 ?{}(&x); // explicit construct x 776 ?{}(y, x); // explit construct y from x 777 ^?{}(&x); // explicit destroy x 218 ?{}(&x); // explicit construct x, second construction 219 ?{}(y, x); // explit construct y from x, second construction 220 ^?{}(&x); // explicit destroy x, in different order 778 221 ^?{}(y); // explicit destroy y 779 222 … … 781 224 // implicit ^?{}(&x); 782 225 \end{cfacode} 783 Calling a constructor or destructor directly is a flexible feature that allows complete control over the management of a piece ofstorage.226 Calling a constructor or destructor directly is a flexible feature that allows complete control over the management of storage. 784 227 In particular, constructors double as a placement syntax. 785 228 \begin{cfacode} … … 804 247 Finally, constructors and destructors support \emph{operator syntax}. 805 248 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. 249 This syntactic form is similar to the new initialization syntax in \CCeleven, except that it is used in expression contexts, rather than declaration contexts. 806 250 \begin{cfacode} 807 251 struct A { ... }; … … 822 266 Destructor operator syntax is actually an statement, and requires parentheses for symmetry with constructor syntax. 823 267 268 One of these three syntactic forms should appeal to either C or \CC programmers using \CFA. 269 270 \subsection{Constructor Expressions} 271 In \CFA, it is possible to use a constructor as an expression. 272 Like other operators, the function name @?{}@ matches its operator syntax. 273 For example, @(&x){}@ calls the default constructor on the variable @x@, and produces @&x@ as a result. 274 A key example for this capability is the use of constructor expressions to initialize the result of a call to standard C routine @malloc@. 275 \begin{cfacode} 276 struct X { ... }; 277 void ?{}(X *, double); 278 X * x = malloc(sizeof(X)){ 1.5 }; 279 \end{cfacode} 280 In this example, @malloc@ dynamically allocates storage and initializes it using a constructor, all before assigning it into the variable @x@. 281 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. 282 \begin{cfacode} 283 X * x = malloc(sizeof(X)); 284 x{ 1.5 }; 285 \end{cfacode} 286 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. 287 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. 288 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. 289 The previous example generates the following code. 290 \begin{cfacode} 291 struct X *_tmp_ctor; 292 struct X *x = ?{}( // construct result of malloc 293 _tmp_ctor=malloc(sizeof(struct X)), // store result of malloc 294 1.5 295 ), _tmp_ctor; // produce constructed result of malloc 296 \end{cfacode} 297 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. 298 299 It is also possible to use operator syntax with destructors. 300 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. 301 For example, \lstinline!^(&x){}! calls the destructor on the variable @x@. 302 824 303 \subsection{Function Generation} 825 In \CFA, every type is defined to have the core set of four functions described previously.304 In \CFA, every type is defined to have the core set of four special functions described previously. 826 305 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. 827 306 In addition to simplifying the definition of the language, it also simplifies the analysis that the translator must perform. … … 833 312 There are several options for user-defined types: structures, unions, and enumerations. 834 313 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. 835 By auto-generating these functions, it is ensured that legacy C code will continueto work correctly in every context where \CFA expects these functions to exist, since they are generated for every complete type.314 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. 836 315 837 316 The generated functions for enumerations are the simplest. 838 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. 839 % TODO: examples for enums 317 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. 840 318 For example, given the enumeration 841 319 \begin{cfacode} … … 850 328 } 851 329 void ?{}(enum Colour *_dst, enum Colour _src){ 852 (*_dst)=_src; // bitwise copy330 *_dst=_src; // bitwise copy 853 331 } 854 332 void ^?{}(enum Colour *_dst){ … … 856 334 } 857 335 enum Colour ?=?(enum Colour *_dst, enum Colour _src){ 858 return (*_dst)=_src; // bitwise copy336 return *_dst=_src; // bitwise copy 859 337 } 860 338 \end{cfacode} 861 339 In the future, \CFA will introduce strongly-typed enumerations, like those in \CC. 862 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.340 The existing generated routines are sufficient to express this restriction, since they are currently set up to take in values of that enumeration type. 863 341 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@. 864 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.342 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. 865 343 866 344 For structures, the situation is more complicated. 867 Fora 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$@.868 That is, a default constructor for @S@ default constructs the members of @S@, the copy constructor with copy constructthem, and so on.869 For example given the structdefinition345 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$@. 346 That is, a default constructor for @S@ default constructs the members of @S@, the copy constructor copy constructs them, and so on. 347 For example, given the structure definition 870 348 \begin{cfacode} 871 349 struct A { … … 893 371 } 894 372 \end{cfacode} 895 It is important to note that the destructors are called in reverse declaration order to resolveconflicts in the event there are dependencies among members.373 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. 896 374 897 375 In addition to the standard set, a set of \emph{field constructors} is also generated for structures. 898 The field constructors are constructors that consume a prefix of the struct 's memberlist.376 The field constructors are constructors that consume a prefix of the structure's member-list. 899 377 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. 900 The addition of field constructors allows struct s 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 }@.378 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 }@. 901 379 Extending the previous example, the following constructors are implicitly generated for @A@. 902 380 \begin{cfacode} … … 911 389 \end{cfacode} 912 390 913 For unions, the default constructor and destructor do nothing, as it is not obvious which member if anyshould be constructed.391 For unions, the default constructor and destructor do nothing, as it is not obvious which member, if any, should be constructed. 914 392 For copy constructor and assignment operations, a bitwise @memcpy@ is applied. 915 393 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. 916 An alter antive 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.394 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. 917 395 This approach ultimately feels subtle and unsafe. 918 396 Another option is to, like \CC, disallow unions from containing members that are themselves managed types. … … 947 425 948 426 % 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 949 In \CCeleven, this restriction has been loosened to allow unions with managed members, with the caveat that anyif 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.427 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. 950 428 This restriction could easily be added into \CFA once \emph{deleted} functions are added. 951 429 … … 970 448 Here, @&s@ and @&s2@ are cast to unqualified pointer types. 971 449 This mechanism allows the same constructors and destructors to be used for qualified objects as for unqualified objects. 972 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. 450 This applies only to implicitly generated constructor calls. 451 Hence, explicitly re-initializing qualified objects with a constructor requires an explicit cast. 452 453 As discussed in Section \ref{sub:c_background}, compound literals create unnamed objects. 454 This mechanism can continue to be used seamlessly in \CFA with managed types to create temporary objects. 455 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. 456 For example, 457 \begin{cfacode} 458 struct A { int x; }; 459 void ?{}(A *, int, int); 460 { 461 int x = (A){ 10, 20 }.x; 462 } 463 \end{cfacode} 464 is equivalent to 465 \begin{cfacode} 466 struct A { int x, y; }; 467 void ?{}(A *, int, int); 468 { 469 A _tmp; 470 ?{}(&_tmp, 10, 20); 471 int x = _tmp.x; 472 ^?{}(&tmp); 473 } 474 \end{cfacode} 973 475 974 476 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. … … 984 486 A a2 @= { 0 }; // unmanaged 985 487 \end{cfacode} 986 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. 987 Instead, @a2->x@ is initialized to @0@ as if it were a C object, due to the explicit initializer. 988 Existing constructors are ignored when \ateq is used, so that any valid C initializer is able to initialize the object. 989 990 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. 488 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. 489 Instead, @a2->x@ is initialized to @0@ as if it were a C object, because of the explicit initializer. 490 491 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. 991 492 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. 992 493 It is recommended that most objects be managed by sensible constructors and destructors, except where absolutely necessary. 993 494 994 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 unlessthe user-defined function goes out of scope.995 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.996 Th is 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??495 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. 496 Furthermore, if the user declares any constructor, then the intrinsic/generated default constructor is also hidden, precluding default construction. 497 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++}. 997 498 \begin{cfacode} 998 499 struct S { int x, y; }; … … 1001 502 S s0, s1 = { 0 }, s2 = { 0, 2 }, s3 = s2; // okay 1002 503 { 1003 void ?{}(S * s, int i) { s->x = i*2; } 504 void ?{}(S * s, int i) { s->x = i*2; } // locally hide autogen constructors 1004 505 S s4; // error 1005 506 S s5 = { 3 }; // okay … … 1014 515 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. 1015 516 If an explicit call is present, then that call is taken in preference to any implicitly generated call. 1016 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 subobject initialization and destruction is always performed based on the declaration order.517 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. 1017 518 \begin{cfacode} 1018 519 struct A { … … 1033 534 } 1034 535 \end{cfacode} 1035 Finally, it is illegal for a sub object to be explicitly constructed for the first time after it is used for the first time.536 Finally, it is illegal for a sub-object to be explicitly constructed for the first time after it is used for the first time. 1036 537 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. 1037 More specifically, the translator searches the body of a constructor to ensure that every sub object is initialized.538 More specifically, the translator searches the body of a constructor to ensure that every sub-object is initialized. 1038 539 \begin{cfacode} 1039 540 void ?{}(A * a, double x) { … … 1042 543 } 1043 544 \end{cfacode} 1044 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 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).545 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). 1045 546 \begin{cfacode} 1046 547 void ?{}(A * a) { … … 1058 559 } // z, y, w implicitly destructed, in this order 1059 560 \end{cfacode} 1060 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).561 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. 1061 562 To override this rule, \ateq can be used to force the translator to trust the programmer's discretion. 1062 563 This form of \ateq is not yet implemented. … … 1064 565 Despite great effort, some forms of C syntax do not work well with constructors in \CFA. 1065 566 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. 1066 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.1067 Furthermore, a function prototype can be repeated an arbitrary number of times, each time using different names.1068 567 \begin{cfacode} 1069 568 // all legal forward declarations in C … … 1076 575 f(b:10, a:20, c:30); // which parameter is which? 1077 576 \end{cfacode} 577 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. 578 Furthermore, a function prototype can be repeated an arbitrary number of times, each time using different names. 1078 579 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. 1079 % 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. 1080 1081 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. 580 581 In addition, constructor calls do not support unnamed nesting. 582 \begin{cfacode} 583 struct B { int x; }; 584 struct C { int y; }; 585 struct A { B b; C c; }; 586 void ?{}(A *, B); 587 void ?{}(A *, C); 588 589 A a = { 590 { 10 }, // construct B? - invalid 591 }; 592 \end{cfacode} 593 In C, nesting initializers means that the programmer intends to initialize sub-objects with the nested initializers. 594 The reason for this omission is to both simplify the mental model for using constructors, and to make initialization simpler for the expression resolver. 595 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. 596 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@. 597 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. 598 599 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. 1082 600 For example, 1083 601 \begin{cfacode} … … 1096 614 } 1097 615 \end{cfacode} 1098 % TODO: in CFA if the array dimension is empty, no object constructors are added -- need to fix this.1099 616 The body of @A@ has been omitted, since only the constructor interfaces are important. 1100 In C, having a greater nesting depth means that the programmer intends to initialize subobjects with the nested initializer. 1101 The reason for this omission is to both simplify the mental model for using constructors, and to make initialization simpler for the expression resolver. 1102 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. 1103 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)@. 1104 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. 617 1105 618 It should be noted that unmanaged objects can still make use of designations and nested initializers in \CFA. 619 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. 1106 620 1107 621 \subsection{Implicit Destructors} … … 1127 641 if (i == 2) return; // destruct x, y 1128 642 } // destruct y 1129 } 1130 \end{cfacode} 1131 1132 %% having this feels excessive, but it's here if necessary 1133 % This procedure generates the following code. 1134 % \begin{cfacode} 1135 % void f(int i){ 1136 % struct A x; 1137 % ?{}(&x); 1138 % { 1139 % struct A y; 1140 % ?{}(&y); 1141 % { 1142 % struct A z; 1143 % ?{}(&z); 1144 % { 1145 % if ((i==0)!=0) { 1146 % ^?{}(&z); 1147 % ^?{}(&y); 1148 % ^?{}(&x); 1149 % return; 1150 % } 1151 % } 1152 % if (((i==1)!=0) { 1153 % ^?{}(&z); 1154 % ^?{}(&y); 1155 % ^?{}(&x); 1156 % return ; 1157 % } 1158 % ^?{}(&z); 1159 % } 1160 1161 % if ((i==2)!=0) { 1162 % ^?{}(&y); 1163 % ^?{}(&x); 1164 % return; 1165 % } 1166 % ^?{}(&y); 1167 % } 1168 1169 % ^?{}(&x); 1170 % } 1171 % \end{cfacode} 643 } // destruct x 644 \end{cfacode} 1172 645 1173 646 The next example illustrates the use of simple continue and break statements and the manner that they interact with implicit destructors. … … 1183 656 \end{cfacode} 1184 657 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. 1185 In the case where @i@ is @2@, the continue statement runs the loop update expression and attemp s to begin the next iteration of the loop.1186 Since continue is a C statement, which does not understand destructors, a destructor call is added just before the continue statementto ensure that @x@ is destructed.658 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. 659 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. 1187 660 When @i@ is @3@, the break statement moves control to just past the end of the loop. 1188 Like the previous case,a destructor call for @x@ is inserted just before the break statement.1189 1190 \CFA also supports label led break and continue statements, which allow more precise manipulation of control flow.1191 Label led break and continue allow the programmer to specify which control structure to target by using a label attached to a control structure.661 Unlike the previous case, the destructor for @x@ cannot be reused, so a destructor call for @x@ is inserted just before the break statement. 662 663 \CFA also supports labeled break and continue statements, which allow more precise manipulation of control flow. 664 Labeled break and continue allow the programmer to specify which control structure to target by using a label attached to a control structure. 1192 665 \begin{cfacode}[emph={L1,L2}, emphstyle=\color{red}] 1193 666 L1: for (int i = 0; i < 10; i++) { 1194 667 A x; 1195 L2:for (int j = 0; j < 10; j++) {668 for (int j = 0; j < 10; j++) { 1196 669 A y; 1197 if (j == 0) { 1198 continue; // destruct y 1199 } else if (j == 1) { 1200 break; // destruct y 1201 } else if (i == 1) { 670 if (i == 1) { 1202 671 continue L1; // destruct y 1203 672 } else if (i == 2) { … … 1208 677 \end{cfacode} 1209 678 The statement @continue L1@ begins the next iteration of the outer for-loop. 1210 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@.1211 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.679 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@. 680 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. 1212 681 1213 682 Finally, an example which demonstrates goto. … … 1256 725 } 1257 726 \end{cfacode} 1258 Labelled break and continue are implemented in \CFA in terms of goto statements, so the more constrained forms are precisely goverened by these rules.727 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. 1259 728 1260 729 The next example demonstrates the error case. … … 1273 742 1274 743 \subsection{Implicit Copy Construction} 744 \label{s:implicit_copy_construction} 1275 745 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. 1276 746 When a value is returned from a function, the copy constructor is called to pass the value back to the call site. 1277 Exempt from these rules are intrinsic and built in functions.747 Exempt from these rules are intrinsic and built-in functions. 1278 748 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. 749 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. 1279 750 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. 1280 751 \begin{cfacode} … … 1284 755 void ^?{}(A *); 1285 756 1286 A f(A x) {1287 return x; 757 A identity(A x) { // pass by value => need local copy 758 return x; // return by value => make call-site copy 1288 759 } 1289 760 1290 761 A y, z @= {}; 1291 identity(y); 1292 identity(z); 762 identity(y); // copy construct y into x 763 identity(z); // copy construct z into x 1293 764 \end{cfacode} 1294 765 Note that @z@ is copy constructed into a temporary variable to be passed as an argument, which is also destructed after the call. 1295 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.1296 766 1297 767 This generates the following 1298 768 \begin{cfacode} 1299 769 struct A f(struct A x){ 1300 struct A _retval_f; 1301 ?{}((&_retval_f), x); 770 struct A _retval_f; // return value 771 ?{}((&_retval_f), x); // copy construct return value 1302 772 return _retval_f; 1303 773 } 1304 774 1305 775 struct A y; 1306 ?{}(&y); 1307 struct A z = { 0 }; 1308 1309 struct A _tmp_cp1; // argument 1 1310 struct A _tmp_cp_ret0; // return value 1311 _tmp_cp_ret0=f((?{}(&_tmp_cp1, y) , _tmp_cp1)), _tmp_cp_ret0; 1312 ^?{}(&_tmp_cp_ret0); // return value 1313 ^?{}(&_tmp_cp1); // argument 1 1314 1315 struct A _tmp_cp2; // argument 1 1316 struct A _tmp_cp_ret1; // return value 1317 _tmp_cp_ret1=f((?{}(&_tmp_cp2, z), _tmp_cp2)), _tmp_cp_ret1; 1318 ^?{}(&_tmp_cp_ret1); // return value 1319 ^?{}(&_tmp_cp2); // argument 1 776 ?{}(&y); // default construct 777 struct A z = { 0 }; // C default 778 779 struct A _tmp_cp1; // argument 1 780 struct A _tmp_cp_ret0; // return value 781 _tmp_cp_ret0=f( 782 (?{}(&_tmp_cp1, y) , _tmp_cp1) // argument is a comma expression 783 ), _tmp_cp_ret0; // return value for cascading 784 ^?{}(&_tmp_cp_ret0); // destruct return value 785 ^?{}(&_tmp_cp1); // destruct argument 1 786 787 struct A _tmp_cp2; // argument 1 788 struct A _tmp_cp_ret1; // return value 789 _tmp_cp_ret1=f( 790 (?{}(&_tmp_cp2, z), _tmp_cp2) // argument is a common expression 791 ), _tmp_cp_ret1; // return value for cascading 792 ^?{}(&_tmp_cp_ret1); // destruct return value 793 ^?{}(&_tmp_cp2); // destruct argument 1 1320 794 ^?{}(&y); 1321 795 \end{cfacode} 1322 796 1323 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. 1324 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. 797 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. 798 \begin{cfacode} 799 identity(z@); // do not copy construct argument 800 // - will copy construct/destruct return value 801 A@ identity_nocopy(A @ x) { // argument not copy constructed or destructed 802 return x; // not copy constructed 803 // return type marked @ => not destructed 804 } 805 \end{cfacode} 806 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. 807 808 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. 809 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. 1325 810 This approach works out most of the time, because typically destructors need to only access the fields of the object and recursively destroy. 1326 It is currently the case that constructors and destructors which use the @this@ pointer as a unique identifier to store data externally willnot work correctly for return value objects.1327 Thus is itnot safe to rely on an object's @this@ pointer to remain constant throughout execution of the program.811 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. 812 Thus, it is currently not safe to rely on an object's @this@ pointer to remain constant throughout execution of the program. 1328 813 \begin{cfacode} 1329 814 A * external_data[32]; … … 1341 826 } 1342 827 } 828 829 A makeA() { 830 A x; // stores &x in external_data 831 return x; 832 } 833 makeA(); // return temporary has a different address than x 834 // equivalent to: 835 // A _tmp; 836 // _tmp = makeA(), _tmp; 837 // ^?{}(&_tmp); 1343 838 \end{cfacode} 1344 839 In the above example, a global array of pointers is used to keep track of all of the allocated @A@ objects. 1345 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.1346 1347 This problem could be solved in the translator by mutating the function signatures so that the return value is moved into the parameter list.840 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@. 841 842 This problem could be solved in the translator by changing the function signatures so that the return value is moved into the parameter list. 1348 843 For example, the translator could restructure the code like so 1349 844 \begin{cfacode} … … 1363 858 \end{cfacode} 1364 859 This transformation provides @f@ with the address of the return variable so that it can be constructed into directly. 1365 It is worth pointing out that this kind of signature rewriting already occurs in polymorphic functions whichreturn by value, as discussed in \cite{Bilson03}.860 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}. 1366 861 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. 1367 862 \begin{cfacode} 1368 863 struct A { int v; }; 1369 A x; // unmanaged 864 A x; // unmanaged, since only trivial constructors are available 1370 865 { 1371 866 void ?{}(A * a) { ... } … … 1375 870 A z; // unmanaged 1376 871 \end{cfacode} 1377 Hence there is not enough information to determine at function declaration to determinewhether 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.872 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. 1378 873 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. 1379 Furthermore, it is n't possible to overload C functions, so using @extern "C"@ to declare functions is of limited use.1380 1381 It would be possible to regain some control by adding an attribute to structs whichspecifies 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.874 Furthermore, it is not possible to overload C functions, so using @extern "C"@ to declare functions is of limited use. 875 876 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. 1382 877 Ideally, structs should be manageable by default, since otherwise the default case becomes more verbose. 1383 878 This means that in general, function signatures would have to be rewritten, and in a select few cases the signatures would not be rewritten. … … 1392 887 \end{cfacode} 1393 888 An alternative is to instead make the attribute \emph{identifiable}, which states that objects of this type use the @this@ parameter as an identity. 1394 This strikes more closely to the visib ile 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.889 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. 1395 890 Furthermore, no restrictions would need to be placed on whether objects can be constructed. 1396 891 \begin{cfacode} … … 1402 897 \end{cfacode} 1403 898 1404 Ultimately, this is the type of transformation that a real compiler would make when generating assembly code.1405 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.1406 As such, it has been decided that this issue is not currently a priority .899 Ultimately, both of these are patchwork solutions. 900 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. 901 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. 1407 902 1408 903 \section{Implementation} 1409 904 \subsection{Array Initialization} 1410 Arrays are a special case in the C type 905 Arrays are a special case in the C type-system. 1411 906 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. 1412 907 Instead, \CFA defines the initialization and destruction of an array recursively. … … 1525 1020 By default, objects within a translation unit are constructed in declaration order, and destructed in the reverse order. 1526 1021 The default order of construction of objects amongst translation units is unspecified. 1527 % TODO: not yet implemented, but g++ provides attribute init_priority, which allows specifying the order of global construction on a per object basis1528 % https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes1529 % 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 level1530 1022 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. 1531 1023 1532 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-Attributes1024 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}. 1533 1025 A similar function is generated with the \emph{destructor} attribute, which handles all global destructor calls. 1534 1026 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. 1535 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.1027 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. 1536 1028 1537 1029 For example, given the following global declarations. … … 1559 1051 \end{cfacode} 1560 1052 1053 % https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes 1054 % 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 1055 GCC provides an attribute @init_priority@, which allows specifying the relative priority for initialization of global objects on a per-object basis in \CC. 1056 A similar attribute can be implemented in \CFA by pulling marked objects into global constructor/destructor-attribute functions with the specified priority. 1057 For example, 1058 \begin{cfacode} 1059 struct A { ... }; 1060 void ?{}(A *, int); 1061 void ^?{}(A *); 1062 __attribute__((init_priority(200))) A x = { 123 }; 1063 \end{cfacode} 1064 would generate 1065 \begin{cfacode} 1066 A x; 1067 __attribute__((constructor(200))) __init_x() { 1068 ?{}(&x, 123); // construct x with priority 200 1069 } 1070 __attribute__((destructor(200))) __destroy_x() { 1071 ?{}(&x); // destruct x with priority 200 1072 } 1073 \end{cfacode} 1074 1561 1075 \subsection{Static Local Variables} 1562 1076 In standard C, it is possible to mark variables that are local to a function with the @static@ storage class. 1563 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??1564 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.1077 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. 1078 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. 1565 1079 1566 1080 Yet again, this rule is too restrictive for a language with constructors and destructors. … … 1573 1087 Construction of @static@ local objects is implemented via an accompanying @static bool@ variable, which records whether the variable has already been constructed. 1574 1088 A conditional branch checks the value of the companion @bool@, and if the variable has not yet been constructed then the object is constructed. 1575 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 willnot reconstruct the object.1089 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. 1576 1090 Since the parameter to @atexit@ is a parameter-less function, some additional tweaking is required. 1577 1091 First, the @static@ variable must be hoisted up to global scope and uniquely renamed to prevent name clashes with other global objects. … … 1579 1093 Finally, the newly generated function is registered with @atexit@, instead of registering the destructor directly. 1580 1094 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. 1581 1582 1095 Extending the previous example 1583 1096 \begin{cfacode} … … 1630 1143 \end{cfacode} 1631 1144 1632 \subsection{Constructor Expressions} 1633 In \CFA, it is possible to use a constructor as an expression. 1634 Like other operators, the function name @?{}@ matches its operator syntax. 1635 For example, @(&x){}@ calls the default constructor on the variable @x@, and produces @&x@ as a result. 1636 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. 1637 A key example is the use of constructor expressions to initialize the result of a call to standard C routine @malloc@. 1638 \begin{cfacode} 1639 struct X { ... }; 1640 void ?{}(X *, double); 1641 X * x = malloc(sizeof(X)){ 1.5 }; 1642 \end{cfacode} 1643 In this example, @malloc@ dynamically allocates storage and initializes it using a constructor, all before assigning it into the variable @x@. 1644 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. 1645 \begin{cfacode} 1646 X * x = malloc(sizeof(X)); 1647 x{ 1.5 }; 1648 \end{cfacode} 1649 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. 1650 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. 1651 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. 1652 The previous example generates the following code. 1653 \begin{cfacode} 1654 struct X *_tmp_ctor; 1655 struct X *x = ?{}((_tmp_ctor=((_tmp_cp_ret0= 1656 malloc(sizeof(struct X))), _tmp_cp_ret0))), 1.5), _tmp_ctor); 1657 \end{cfacode} 1658 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. 1659 1660 It is also possible to use operator syntax with destructors. 1661 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. 1662 For example, \lstinline!^(&x){}! calls the destructor on the variable @x@. 1145 \subsection{Polymorphism} 1146 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@. 1147 In previous versions of \CFA, @otype@ was syntactic sugar for @dtype@ with known size/alignment information and an assignment function. 1148 That is, 1149 \begin{cfacode} 1150 forall(otype T) 1151 void f(T); 1152 \end{cfacode} 1153 was equivalent to 1154 \begin{cfacode} 1155 forall(dtype T | sized(T) | { T ?=?(T *, T); }) 1156 void f(T); 1157 \end{cfacode} 1158 This allows easily specifying constraints that are common to all complete object types very simply. 1159 1160 Now that \CFA has constructors and destructors, more of a complete object's behaviour can be specified by than was previously possible. 1161 As such, @otype@ has been augmented to include assertions for a default constructor, copy constructor, and destructor. 1162 That is, the previous example is now equivalent to 1163 \begin{cfacode} 1164 forall(dtype T | sized(T) | { T ?=?(T *, T); void ?{}(T *); void ?{}(T *, T); void ^?{}(T *); }) 1165 void f(T); 1166 \end{cfacode} 1167 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. 1168 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.