Changeset 12d3187 for doc/rob_thesis/conclusions.tex
- Timestamp:
- May 1, 2017, 1:39:55 PM (7 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, 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
- Children:
- 2055098
- Parents:
- b3d70eba
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/rob_thesis/conclusions.tex
rb3d70eba r12d3187 6 6 On the surface, the work may appear as a rehash of similar mechanisms in \CC. 7 7 However, 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. 8 All of these new features are being used extensively by the \CFA development-team to build the \CFA runtime system. 9 In 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@. 9 10 10 11 \section{Constructors and Destructors} … … 245 246 That 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. 246 247 A 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 .248 This approach could be added to \CFA, but it requires an idiomatic way of specifying what code is privileged and what data is protected. 248 249 One possibility is to tie access control into an eventual module system. 250 251 \begin{sloppypar} 252 The current implementation of implicit subobject-construction is currently an all-or-nothing check. 253 That is, if a subobject is conditionally constructed, \eg within an if-statement, no implicit constructors for that object are added. 254 \begin{cfacode} 255 struct A { ... }; 256 void ?{}(A * a) { ... } 257 258 struct B { 259 A a; 260 }; 261 void ?{}(B * b) { 262 if (...) { 263 (&b->a){}; // explicitly constructed 264 } // does not construct in else case 265 } 266 \end{cfacode} 267 This behaviour is unsafe and breaks the guarantee that constructors fully initialize objects. 268 This 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. 269 \end{sloppypar} 249 270 250 271 \subsection{Tuples} … … 252 273 This feature ties nicely into named tuples, as seen in D and Swift. 253 274 254 Currently, tuple flattening and structuring conversions are 0-cost .275 Currently, tuple flattening and structuring conversions are 0-cost conversions in the resolution algorithm. 255 276 This 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. 256 277 Adding 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.