May 1, 2017, 1:39:55 PM (5 years ago)
Rob Schluntz <rschlunt@…>
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc

final revisions to thesis

1 edited


  • doc/rob_thesis/conclusions.tex

    rb3d70eb r12d3187  
    66On the surface, the work may appear as a rehash of similar mechanisms in \CC.
    77However, every added feature is different than its \CC counterpart, often with extended functionality, better integration with C and its programmers, and always supports separate compilation.
    8 All of these new features are being used by the \CFA development-team to build the \CFA runtime system.
     8All of these new features are being used extensively by the \CFA development-team to build the \CFA runtime system.
     9In particular, the concurrency system is built on top of RAII, library functions @new@ and @delete@ are used to manage dynamically allocated objects, and tuples are used to provide uniform interfaces to C library routines such as @div@ and @remquo@.
    1011\section{Constructors and Destructors}
    245246That is, structure fields can be accessed and modified by any block of code without restriction, so while it is possible to ensure that an object is initially set to a valid state, it is not possible to ensure that it remains in a consistent state throughout its lifetime.
    246247A popular technique for ensuring consistency in object-oriented programming languages is to provide access modifiers such as @private@, which provides compile-time checks that only privileged code accesses private data.
    247 This approach could be added to \CFA, but it requires an idiomatic way of specifying what code is privileged.
     248This approach could be added to \CFA, but it requires an idiomatic way of specifying what code is privileged and what data is protected.
    248249One possibility is to tie access control into an eventual module system.
     252The current implementation of implicit subobject-construction is currently an all-or-nothing check.
     253That is, if a subobject is conditionally constructed, \eg within an if-statement, no implicit constructors for that object are added.
     255struct A { ... };
     256void ?{}(A * a) { ... }
     258struct B {
     259  A a;
     261void ?{}(B * b) {
     262  if (...) {
     263    (&b->a){};  // explicitly constructed
     264  } // does not construct in else case
     267This behaviour is unsafe and breaks the guarantee that constructors fully initialize objects.
     268This situation should be properly handled, either by examining all paths and inserting implicit constructor calls only in the paths missing construction, or by emitting an error or warning.
    252273This feature ties nicely into named tuples, as seen in D and Swift.
    254 Currently, tuple flattening and structuring conversions are 0-cost.
     275Currently, tuple flattening and structuring conversions are 0-cost conversions in the resolution algorithm.
    255276This makes tuples conceptually very simple to work with, but easily causes unnecessary ambiguity in situations where the type system should be able to differentiate between alternatives.
    256277Adding an appropriate cost function to tuple conversions will allow tuples to interact with the rest of the programming language more cohesively.
Note: See TracChangeset for help on using the changeset viewer.