# source:doc/proposals/ctordtor/ctor.tex@83a09648

Last change on this file since 83a09648 was 484ee53, checked in by Peter A. Buhr <pabuhr@…>, 4 years ago

280
281\subsection{Using Constructors and Destructors}
282Implicitly generated constructor and destructor calls ignore the outermost type qualifiers on a type by way of a cast on the first argument to the function.
283This mechanism allows the same constructors and destructors to be used for qualified objects as for unqualified objects.
284Since this applies only to implicitly generated constructor calls, the language will not allow qualified objects to be re-initialized with a constructor without an explicit cast.
285
286Unlike \CC, \CFA provides an escape hatch that allows a user to decide at an object's definition whether it should be managed or not.
287An object initialized with \lstinline{@=} is guaranteed to be initialized like a C object, and will not be implicitly destructed.
288This feature provides all of the freedom that C programmers are used to having to optimize the program, while maintaining safety as a sensible default.
289In addition to freedom, \lstinline{@=} 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.
290It is worth noting that the use of unmanaged objects can be tricky to get right, since there is no guarantee that the proper invariants will be established on an unmanaged object.
291It is recommended that most objects are managed by sensible constructors and destructors, except where absolutely necessary.
292
293When the user defines any constructor, the intrinsic/generated functions become invisible.
294In the current implementation, the default constructor and copy constructor are only hidden when explicitly overriden, since the derefence operator ©*?© is currently an ©otype© function, which would make it impossible to override a constructor, due to the lack of assertion-satifying funcitons.
295There is a proposal which decouples size/alignment type information from ©otype©, and implementing this would allow constructors and destructors to be hidden by the same rules that \CC uses.
296
297% TODO discuss compile time "checks" for subobjects when defining ctor/dtor for struct
298When defining a constructor or destructor for a struct ©S©, any members that are not explicitly constructed or destructed will be implicitly constructed or destructed automatically.
299If an explicit call is present, then that call is taken in preference to any implicitly generated call.
300A consequence of this rule is that it is possible, unlike \CC, to precisely control the order of construction and destruction of subobjects on a per-constructor basis, whereas in \CC subobject initialization and destruction is always performed based on the declaration order.
301Finally, it is illegal for a subobject to be explicitly constructed after it is used for the first time.
302If the translator cannot be reasonably sure that an object is constructed prior to its first use, but may be constructed afterward, and error is emitted.
303To override this rule, \lstinline{@=} can be used to force the translator to trust the programmer's discretion.
304This form of \lstinline{@=} is not yet implemented.
305
306% TODO discuss error if initializer nesting is too deep or contains designations
307Despite great effort, some forms of C syntax do not work well with constructors in \CFA.
308In particular, constructor calls cannot contain designations, since this is equivalent to allowing designations on the arguments to arbitrary function calls.
309In 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.
310Furthermore, a function prototype can be repeated an arbitrary number of times, each time using different names.
311As 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.
312In addition, constructor calls cannot have a nesting depth greater than the number of array components in the type of the initialized object, plus one.
313In C, having a greater nesting depth would mean that the programmer intends to initialize subobjects with the nested initializer.
314The reason for this omission is to both simplify the mental model for using constructors, and to make the case of initialization simpler for the resolver.
315If 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 to one of the available constructors, making the problem highly recursive and potentially much more expensive.
316It should be noted that if an object does not have a non-trivial constructor, it can still make use of designations and nested initializers in \CFA.
317
318% TODO section on where destruction occurs - probably belongs in implementation section? or part of it does, anyway
319Destructors are automatically called at the end of the block in which the object was declared.
320In addition to this, destructors are automatically called when statements manipulate control flow to leave the block in which the object is declared, e.g. with return, break, continue, and goto statements.
321
322% TODO discuss copy construction for function parameters and return values
323When a function is called, the arguments supplied to the call are subject to implicit copy construction, and the return value is subject to destruction.
324When a value is returned from a function, the copy constructor is called to pass the value back to the call site.
325Exempt from these rules are intrinsic and builtin functions.
326
327% TODO discuss ©= + copy construction?
328
329% \subsection{Implementation}
330% Discuss the implementation details of constructors and destructors.
331
332\end{document}
Note: See TracBrowser for help on using the repository browser.