Changes in doc/rob_thesis/conclusions.tex [12d3187:0111dc7]
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/rob_thesis/conclusions.tex
r12d3187 r0111dc7 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 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@. 8 All of these new features are being used by the \CFA development-team to build the \CFA runtime system. 10 9 11 10 \section{Constructors and Destructors} … … 246 245 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. 247 246 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. 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.247 This approach could be added to \CFA, but it requires an idiomatic way of specifying what code is privileged. 249 248 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 constructed264 } // does not construct in else case265 }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}270 249 271 250 \subsection{Tuples} … … 273 252 This feature ties nicely into named tuples, as seen in D and Swift. 274 253 275 Currently, tuple flattening and structuring conversions are 0-cost conversions in the resolution algorithm.254 Currently, tuple flattening and structuring conversions are 0-cost. 276 255 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. 277 256 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.