- Timestamp:
- Feb 9, 2018, 4:30:17 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:
- 826a67c
- Parents:
- 119bb6a (diff), a722c7a (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the(diff)
links above to see all the changes relative to each parent. - File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/papers/general/Paper.tex
r119bb6a r92f8e18 102 102 \makeatother 103 103 104 \newenvironment{cquote}{% 105 \list{}{\lstset{resetmargins=true,aboveskip=0pt,belowskip=0pt}\topsep=4pt\parsep=0pt\leftmargin=\parindent\rightmargin\leftmargin}% 106 \item\relax 107 }{% 108 \endlist 109 }% cquote 110 104 111 % CFA programming language, based on ANSI C (with some gcc additions) 105 112 \lstdefinelanguage{CFA}[ANSI]{C}{ … … 227 234 int forty_two = identity( 42 ); $\C{// T is bound to int, forty\_two == 42}$ 228 235 \end{lstlisting} 229 The @identity@ function above can be applied to any complete \ emph{object type} (or @otype@).236 The @identity@ function above can be applied to any complete \newterm{object type} (or @otype@). 230 237 The type variable @T@ is transformed into a set of additional implicit parameters encoding sufficient information about @T@ to create and return a variable of that type. 231 238 The \CFA implementation passes the size and alignment of the type represented by an @otype@ parameter, as well as an assignment operator, constructor, copy constructor and destructor. 232 If this extra information is not needed, \eg for a pointer, the type parameter can be declared as a \ emph{data type} (or @dtype@).239 If this extra information is not needed, \eg for a pointer, the type parameter can be declared as a \newterm{data type} (or @dtype@). 233 240 234 241 In \CFA, the polymorphism runtime-cost is spread over each polymorphic call, due to passing more arguments to polymorphic functions; … … 236 243 A design advantage is that, unlike \CC template-functions, \CFA polymorphic-functions are compatible with C \emph{separate compilation}, preventing compilation and code bloat. 237 244 238 Since bare polymorphic-types provide a restricted set of available operations, \CFA provides a \ emph{type assertion}~\cite[pp.~37-44]{Alphard} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type-variable.245 Since bare polymorphic-types provide a restricted set of available operations, \CFA provides a \newterm{type assertion}~\cite[pp.~37-44]{Alphard} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type-variable. 239 246 For example, the function @twice@ can be defined using the \CFA syntax for operator overloading: 240 247 \begin{lstlisting} … … 306 313 \subsection{Traits} 307 314 308 \CFA provides \ emph{traits} to name a group of type assertions, where the trait name allows specifying the same set of assertions in multiple locations, preventing repetition mistakes at each function declaration:315 \CFA provides \newterm{traits} to name a group of type assertions, where the trait name allows specifying the same set of assertions in multiple locations, preventing repetition mistakes at each function declaration: 309 316 \begin{lstlisting} 310 317 trait summable( otype T ) { … … 330 337 Given the information provided for an @otype@, variables of polymorphic type can be treated as if they were a complete type: stack-allocatable, default or copy-initialized, assigned, and deleted. 331 338 332 In summation, the \CFA type-system uses \ emph{nominal typing} for concrete types, matching with the C type-system, and \emph{structural typing} for polymorphic types.339 In summation, the \CFA type-system uses \newterm{nominal typing} for concrete types, matching with the C type-system, and \newterm{structural typing} for polymorphic types. 333 340 Hence, trait names play no part in type equivalence; 334 341 the names are simply macros for a list of polymorphic assertions, which are expanded at usage sites. … … 375 382 Furthermore, writing and using preprocessor macros can be unnatural and inflexible. 376 383 377 \CC, Java, and other languages use \ emph{generic types} to produce type-safe abstract data-types.384 \CC, Java, and other languages use \newterm{generic types} to produce type-safe abstract data-types. 378 385 \CFA also implements generic types that integrate efficiently and naturally with the existing polymorphic functions, while retaining backwards compatibility with C and providing separate compilation. 379 386 However, for known concrete parameters, the generic-type definition can be inlined, like \CC templates. … … 396 403 \end{lstlisting} 397 404 398 \CFA classifies generic types as either \ emph{concrete} or \emph{dynamic}.405 \CFA classifies generic types as either \newterm{concrete} or \newterm{dynamic}. 399 406 Concrete types have a fixed memory layout regardless of type parameters, while dynamic types vary in memory layout depending on their type parameters. 400 A type may have polymorphic parameters but still be concrete, called \ emph{dtype-static}.407 A type may have polymorphic parameters but still be concrete, called \newterm{dtype-static}. 401 408 Polymorphic pointers are an example of dtype-static types, \eg @forall(dtype T) T *@ is a polymorphic type, but for any @T@, @T *@ is a fixed-sized pointer, and therefore, can be represented by a @void *@ in code generation. 402 409 … … 435 442 Though \CFA implements concrete generic-types efficiently, it also has a fully general system for dynamic generic types. 436 443 As mentioned in Section~\ref{sec:poly-fns}, @otype@ function parameters (in fact all @sized@ polymorphic parameters) come with implicit size and alignment parameters provided by the caller. 437 Dynamic generic-types also have an \ emph{offset array} containing structure-member offsets.444 Dynamic generic-types also have an \newterm{offset array} containing structure-member offsets. 438 445 A dynamic generic-union needs no such offset array, as all members are at offset 0, but size and alignment are still necessary. 439 446 Access to members of a dynamic structure is provided at runtime via base-displacement addressing with the structure pointer and the member offset (similar to the @offsetof@ macro), moving a compile-time offset calculation to runtime. … … 448 455 For instance, modularity is generally provided in C by including an opaque forward-declaration of a structure and associated accessor and mutator functions in a header file, with the actual implementations in a separately-compiled @.c@ file. 449 456 \CFA supports this pattern for generic types, but the caller does not know the actual layout or size of the dynamic generic-type, and only holds it by a pointer. 450 The \CFA translator automatically generates \ emph{layout functions} for cases where the size, alignment, and offset array of a generic struct cannot be passed into a function from that function's caller.457 The \CFA translator automatically generates \newterm{layout functions} for cases where the size, alignment, and offset array of a generic struct cannot be passed into a function from that function's caller. 451 458 These layout functions take as arguments pointers to size and alignment variables and a caller-allocated array of member offsets, as well as the size and alignment of all @sized@ parameters to the generic structure (un@sized@ parameters are forbidden from being used in a context that affects layout). 452 459 Results of these layout functions are cached so that they are only computed once per type per function. %, as in the example below for @pair@. … … 472 479 Since @pair(T *, T * )@ is a concrete type, there are no implicit parameters passed to @lexcmp@, so the generated code is identical to a function written in standard C using @void *@, yet the \CFA version is type-checked to ensure the fields of both pairs and the arguments to the comparison function match in type. 473 480 474 Another useful pattern enabled by reused dtype-static type instantiations is zero-cost \ emph{tag-structures}.481 Another useful pattern enabled by reused dtype-static type instantiations is zero-cost \newterm{tag-structures}. 475 482 Sometimes information is only used for type-checking and can be omitted at runtime, \eg: 476 483 \begin{lstlisting} … … 528 535 The addition of multiple-return-value functions (MRVF) are useless without a syntax for accepting multiple values at the call-site. 529 536 The simplest mechanism for capturing the return values is variable assignment, allowing the values to be retrieved directly. 530 As such, \CFA allows assigning multiple values from a function into multiple variables, using a square-bracketed list of lvalue expressions (as above), called a \ emph{tuple}.531 532 However, functions also use \ emph{composition} (nested calls), with the direct consequence that MRVFs must also support composition to be orthogonal with single-returning-value functions (SRVF), \eg:537 As such, \CFA allows assigning multiple values from a function into multiple variables, using a square-bracketed list of lvalue expressions (as above), called a \newterm{tuple}. 538 539 However, functions also use \newterm{composition} (nested calls), with the direct consequence that MRVFs must also support composition to be orthogonal with single-returning-value functions (SRVF), \eg: 533 540 \begin{lstlisting} 534 541 printf( "%d %d\n", div( 13, 5 ) ); $\C{// return values seperated into arguments}$ … … 563 570 printf( "%d %d\n", qr ); 564 571 \end{lstlisting} 565 \CFA also supports \ emph{tuple indexing} to access single components of a tuple expression:572 \CFA also supports \newterm{tuple indexing} to access single components of a tuple expression: 566 573 \begin{lstlisting} 567 574 [int, int] * p = &qr; $\C{// tuple pointer}$ … … 606 613 \subsection{Tuple Assignment} 607 614 608 An assignment where the left side is a tuple type is called \ emph{tuple assignment}.609 There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a tuple type or a non-tuple type, called \ emph{multiple} and \emph{mass assignment}, respectively.615 An assignment where the left side is a tuple type is called \newterm{tuple assignment}. 616 There are two kinds of tuple assignment depending on whether the right side of the assignment operator has a tuple type or a non-tuple type, called \newterm{multiple} and \newterm{mass assignment}, respectively. 610 617 %\lstDeleteShortInline@% 611 618 %\par\smallskip … … 641 648 \subsection{Member Access} 642 649 643 It is also possible to access multiple fields from a single expression using a \ emph{member-access}.650 It is also possible to access multiple fields from a single expression using a \newterm{member-access}. 644 651 The result is a single tuple-valued expression whose type is the tuple of the types of the members, \eg: 645 652 \begin{lstlisting} … … 771 778 Matching against a @ttype@ parameter consumes all remaining argument components and packages them into a tuple, binding to the resulting tuple of types. 772 779 In a given parameter list, there must be at most one @ttype@ parameter that occurs last, which matches normal variadic semantics, with a strong feeling of similarity to \CCeleven variadic templates. 773 As such, @ttype@ variables are also called \ emph{argument packs}.780 As such, @ttype@ variables are also called \newterm{argument packs}. 774 781 775 782 Like variadic templates, the main way to manipulate @ttype@ polymorphic functions is via recursion. … … 843 850 \subsection{Implementation} 844 851 845 Tuples are implemented in the \CFA translator via a transformation into \ emph{generic types}.852 Tuples are implemented in the \CFA translator via a transformation into \newterm{generic types}. 846 853 For each $N$, the first time an $N$-tuple is seen in a scope a generic type with $N$ type parameters is generated, \eg: 847 854 \begin{lstlisting} … … 894 901 Similarly, tuple member expressions are recursively expanded into a list of member access expressions. 895 902 896 Expressions that may contain side effects are made into \ emph{unique expressions} before being expanded by the flattening conversion.903 Expressions that may contain side effects are made into \newterm{unique expressions} before being expanded by the flattening conversion. 897 904 Each unique expression is assigned an identifier and is guaranteed to be executed exactly once: 898 905 \begin{lstlisting} … … 1081 1088 % In object-oriented programming, there is an implicit first parameter, often names @self@ or @this@, which is elided. 1082 1089 % In any programming language, some functions have a naturally close relationship with a particular data type. 1083 % Object-oriented programming allows this close relationship to be codified in the language by making such functions \ emph{class methods} of their related data type.1090 % Object-oriented programming allows this close relationship to be codified in the language by making such functions \newterm{class methods} of their related data type. 1084 1091 % Class methods have certain privileges with respect to their associated data type, notably un-prefixed access to the fields of that data type. 1085 1092 % When writing C functions in an object-oriented style, this un-prefixed access is swiftly missed, as access to fields of a @Foo* f@ requires an extra three characters @f->@ every time, which disrupts coding flow and clutters the produced code. … … 1195 1202 C declaration syntax is notoriously confusing and error prone. 1196 1203 For example, many C programmers are confused by a declaration as simple as: 1197 \begin{ flushleft}1204 \begin{cquote} 1198 1205 \lstDeleteShortInline@% 1199 1206 \begin{tabular}{@{}ll@{}} … … 1205 1212 \end{tabular} 1206 1213 \lstMakeShortInline@% 1207 \end{ flushleft}1214 \end{cquote} 1208 1215 Is this an array of 5 pointers to integers or a pointer to an array of 5 integers? 1209 The fact this declaration is unclear to many C programmers means there areproductivity and safety issues even for basic programs.1216 If there is any doubt, it implies productivity and safety issues even for basic programs. 1210 1217 Another example of confusion results from the fact that a routine name and its parameters are embedded within the return type, mimicking the way the return value is used at the routine's call site. 1211 1218 For example, a routine returning a pointer to an array of integers is defined and used in the following way: … … 1221 1228 In the following example, \R{red} is the base type and \B{blue} is qualifiers. 1222 1229 The \CFA declarations move the qualifiers to the left of the base type, \ie move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type. 1223 \begin{ quote}1230 \begin{cquote} 1224 1231 \lstDeleteShortInline@% 1225 1232 \lstset{moredelim=**[is][\color{blue}]{+}{+}} … … 1239 1246 \end{tabular} 1240 1247 \lstMakeShortInline@% 1241 \end{ quote}1248 \end{cquote} 1242 1249 The only exception is bit field specification, which always appear to the right of the base type. 1243 % Specifically, the character ©*© is used to indicate a pointer, square brackets ©[©\,©]© are used to represent an array or function return value, and parentheses ©()©are used to indicate a routine parameter.1250 % Specifically, the character @*@ is used to indicate a pointer, square brackets @[@\,@]@ are used to represent an array or function return value, and parentheses @()@ are used to indicate a routine parameter. 1244 1251 However, unlike C, \CFA type declaration tokens are distributed across all variables in the declaration list. 1245 For instance, variables ©x© and ©y©of type pointer to integer are defined in \CFA as follows:1246 \begin{ quote}1252 For instance, variables @x@ and @y@ of type pointer to integer are defined in \CFA as follows: 1253 \begin{cquote} 1247 1254 \lstDeleteShortInline@% 1248 1255 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} … … 1257 1264 \end{tabular} 1258 1265 \lstMakeShortInline@% 1259 \end{ quote}1266 \end{cquote} 1260 1267 The downside of this semantics is the need to separate regular and pointer declarations: 1261 \begin{ quote}1268 \begin{cquote} 1262 1269 \lstDeleteShortInline@% 1263 1270 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} … … 1274 1281 \end{tabular} 1275 1282 \lstMakeShortInline@% 1276 \end{ quote}1283 \end{cquote} 1277 1284 which is prescribing a safety benefit. 1278 1285 Other examples are: 1279 \begin{ quote}1286 \begin{cquote} 1280 1287 \lstDeleteShortInline@% 1281 1288 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} … … 1315 1322 \end{tabular} 1316 1323 \lstMakeShortInline@% 1317 \end{ quote}1318 1319 All type qualifiers, \eg ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, \eg:1320 \begin{ quote}1324 \end{cquote} 1325 1326 All type qualifiers, \eg @const@, @volatile@, etc., are used in the normal way with the new declarations and also appear left to right, \eg: 1327 \begin{cquote} 1321 1328 \lstDeleteShortInline@% 1322 1329 \begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}} … … 1338 1345 \end{tabular} 1339 1346 \lstMakeShortInline@% 1340 \end{ quote}1341 All declaration qualifiers, \eg ©extern©, ©static©, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier}1347 \end{cquote} 1348 All declaration qualifiers, \eg @extern@, @static@, etc., are used in the normal way with the new declarations but can only appear at the start of a \CFA routine declaration,\footnote{\label{StorageClassSpecifier} 1342 1349 The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.~\cite[\S~6.11.5(1)]{C11}} \eg: 1343 \begin{ quote}1350 \begin{cquote} 1344 1351 \lstDeleteShortInline@% 1345 1352 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} … … 1361 1368 \end{tabular} 1362 1369 \lstMakeShortInline@% 1363 \end{ quote}1364 1365 The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©:1366 \begin{ quote}1370 \end{cquote} 1371 1372 The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine @sizeof@: 1373 \begin{cquote} 1367 1374 \lstDeleteShortInline@% 1368 1375 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1369 1376 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 1370 1377 \begin{cfa} 1371 y = ( `* int`)x;1372 i = sizeof( `[ 5 ] * int`);1378 y = (* int)x; 1379 i = sizeof([ 5 ] * int); 1373 1380 \end{cfa} 1374 1381 & 1375 1382 \begin{cfa} 1376 y = ( `int *`)x;1377 i = sizeof( `int * [ 5 ]`);1383 y = (int *)x; 1384 i = sizeof(int * [ 5 ]); 1378 1385 \end{cfa} 1379 1386 \end{tabular} 1380 1387 \lstMakeShortInline@% 1381 \end{ quote}1388 \end{cquote} 1382 1389 1383 1390 Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration. 1384 1391 Therefore, a programmer has the option of either continuing to use traditional C declarations or take advantage of the new style. 1385 Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX systems.1392 Clearly, both styles need to be supported for some time due to existing C-style header-files, particularly for UNIX-like systems. 1386 1393 1387 1394 1388 1395 \subsection{References} 1389 1396 1390 All variables in C have an \emph{address}, a \emph{value}, and a \emph{type}; at the position in the program's memory denoted by the address, there exists a sequence of bits (the value), with the length and semantic meaning of this bit sequence defined by the type. 1391 The C type system does not always track the relationship between a value and its address; a value that does not have a corresponding address is called a \emph{rvalue} (for ``right-hand value''), while a value that does have an address is called a \emph{lvalue} (for ``left-hand value''); in @int x; x = 42;@ the variable expression @x@ on the left-hand-side of the assignment is a lvalue, while the constant expression @42@ on the right-hand-side of the assignment is a rvalue. 1392 Which address a value is located at is sometimes significant; the imperative programming paradigm of C relies on the mutation of values at specific addresses. 1393 Within a lexical scope, lvalue exressions can be used in either their \emph{address interpretation} to determine where a mutated value should be stored or in their \emph{value interpretation} to refer to their stored value; in @x = y;@ in @{ int x, y = 7; x = y; }@, @x@ is used in its address interpretation, while y is used in its value interpretation. 1394 Though this duality of interpretation is useful, C lacks a direct mechanism to pass lvalues between contexts, instead relying on \emph{pointer types} to serve a similar purpose. 1395 In C, for any type @T@ there is a pointer type @T*@, the value of which is the address of a value of type @T@; a pointer rvalue can be explicitly \emph{dereferenced} to the pointed-to lvalue with the dereference operator @*?@, while the rvalue representing the address of a lvalue can be obtained with the address-of operator @&?@. 1397 All variables in C have an \newterm{address}, a \newterm{value}, and a \newterm{type}; 1398 at the position in the program's memory denoted by the address, there exists a sequence of bits (the value), with the length and semantic meaning of this bit sequence defined by the type. 1399 The C type-system does not always track the relationship between a value and its address; 1400 a value that does not have a corresponding address is called a \newterm{rvalue} (for ``right-hand value''), while a value that does have an address is called a \newterm{lvalue} (for ``left-hand value''). 1401 For example, in @int x; x = 42;@ the variable expression @x@ on the left-hand-side of the assignment is a lvalue, while the constant expression @42@ on the right-hand-side of the assignment is a rvalue. 1402 In imperative programming, the address of a value is used for both reading and writing (mutating) a value. 1403 1404 Within a lexical scope, lvalue expressions have an \newterm{address interpretation} for writing a value or a \newterm{value interpretation} to read a value. 1405 For example, in @x = y@, @x@ has an address interpretation, while @y@ has a value interpretation. 1406 Though this duality of interpretation is useful, C lacks a direct mechanism to pass lvalues between contexts, instead relying on \newterm{pointer types} to serve a similar purpose. 1407 In C, for any type @T@ there is a pointer type @T *@, the value of which is the address of a value of type @T@. 1408 A pointer rvalue can be explicitly \newterm{dereferenced} to the pointed-to lvalue with the dereference operator @*?@, while the rvalue representing the address of a lvalue can be obtained with the address-of operator @&?@. 1396 1409 1397 1410 \begin{cfa} 1398 1411 int x = 1, y = 2, * p1, * p2, ** p3; 1399 p1 = &x; 1400 p2 = &y; 1401 p3 = &p1; 1412 p1 = &x; $\C{// p1 points to x}$ 1413 p2 = &y; $\C{// p2 points to y}$ 1414 p3 = &p1; $\C{// p3 points to p1}$ 1402 1415 *p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15); 1403 1416 \end{cfa} … … 1405 1418 Unfortunately, the dereference and address-of operators introduce a great deal of syntactic noise when dealing with pointed-to values rather than pointers, as well as the potential for subtle bugs. 1406 1419 For both brevity and clarity, it would be desirable to have the compiler figure out how to elide the dereference operators in a complex expression such as the assignment to @*p2@ above. 1407 However, since C defines a number of forms of \ emph{pointer arithmetic}, two similar expressions involving pointers to arithmetic types (\eg @*p1 + x@ and @p1 + x@) may each have well-defined but distinct semantics, introducing the possibility that a user programmer may write one when they mean the other, and precluding any simple algorithm for elision of dereference operators.1420 However, since C defines a number of forms of \newterm{pointer arithmetic}, two similar expressions involving pointers to arithmetic types (\eg @*p1 + x@ and @p1 + x@) may each have well-defined but distinct semantics, introducing the possibility that a user programmer may write one when they mean the other, and precluding any simple algorithm for elision of dereference operators. 1408 1421 To solve these problems, \CFA introduces reference types @T&@; a @T&@ has exactly the same value as a @T*@, but where the @T*@ takes the address interpretation by default, a @T&@ takes the value interpretation by default, as below: 1409 1422 1410 1423 \begin{cfa} 1411 in xx = 1, y = 2, & r1, & r2, && r3;1424 int x = 1, y = 2, & r1, & r2, && r3; 1412 1425 &r1 = &x; $\C{// r1 points to x}$ 1413 1426 &r2 = &y; $\C{// r2 points to y}$ … … 1431 1444 This allows \CFA references to be default-initialized (\eg to a null pointer), and also to point to different addresses throughout their lifetime. 1432 1445 This rebinding is accomplished without adding any new syntax to \CFA, but simply by extending the existing semantics of the address-of operator in C. 1446 1433 1447 In C, the address of a lvalue is always a rvalue, as in general that address is not stored anywhere in memory, and does not itself have an address. 1434 1448 In \CFA, the address of a @T&@ is a lvalue @T*@, as the address of the underlying @T@ is stored in the reference, and can thus be mutated there. … … 1444 1458 if @L@ is an lvalue of type {@T &@$_1 \cdots$@ &@$_l$} where $l \ge 0$ references (@&@ symbols) then @&L@ has type {@T `*`&@$_{\color{red}1} \cdots$@ &@$_{\color{red}l}$}, \\ \ie @T@ pointer with $l$ references (@&@ symbols). 1445 1459 \end{itemize} 1446 1447 1460 Since pointers and references share the same internal representation, code using either is equally performant; in fact the \CFA compiler converts references to pointers internally, and the choice between them in user code can be made based solely on convenience. 1461 1448 1462 By analogy to pointers, \CFA references also allow cv-qualifiers: 1449 1463 … … 1464 1478 1465 1479 More generally, this initialization of references from lvalues rather than pointers is an instance of a ``lvalue-to-reference'' conversion rather than an elision of the address-of operator; this conversion can actually be used in any context in \CFA an implicit conversion would be allowed. 1466 Similarly, use of a the value pointed to by a reference in an rvalue context can be thought of as a ``reference-to-rvalue'' conversion, and \CFA also includes a qualifier-adding ``reference-to-reference'' conversion, anal agous to the @T *@ to @const T *@ conversion in standard C.1480 Similarly, use of a the value pointed to by a reference in an rvalue context can be thought of as a ``reference-to-rvalue'' conversion, and \CFA also includes a qualifier-adding ``reference-to-reference'' conversion, analogous to the @T *@ to @const T *@ conversion in standard C. 1467 1481 The final reference conversion included in \CFA is ``rvalue-to-reference'' conversion, implemented by means of an implicit temporary. 1468 1482 When an rvalue is used to initialize a reference, it is instead used to initialize a hidden temporary value with the same lexical scope as the reference, and the reference is initialized to the address of this temporary. 1469 1483 This allows complex values to be succinctly and efficiently passed to functions, without the syntactic overhead of explicit definition of a temporary variable or the runtime cost of pass-by-value. 1470 \CC allows a similar binding, but only for @const@ references; the more general semantics of \CFA are an attempt to avoid the \emph{const hell} problem, in which addition of a @const@ qualifier to one reference requires a cascading chain of added qualifiers. 1484 \CC allows a similar binding, but only for @const@ references; the more general semantics of \CFA are an attempt to avoid the \newterm{const hell} problem, in which addition of a @const@ qualifier to one reference requires a cascading chain of added qualifiers. 1485 1471 1486 1472 1487 \subsection{Constructors and Destructors} … … 1474 1489 One of the strengths of C is the control over memory management it gives programmers, allowing resource release to be more consistent and precisely timed than is possible with garbage-collected memory management. 1475 1490 However, this manual approach to memory management is often verbose, and it is useful to manage resources other than memory (\eg file handles) using the same mechanism as memory. 1476 \CC is well-known for an approach to manual memory management that addresses both these issues, Resource Aquisition Is Initialization (RAII), implemented by means of special \ emph{constructor} and \emph{destructor} functions; we have implemented a similar feature in \CFA.1491 \CC is well-known for an approach to manual memory management that addresses both these issues, Resource Aquisition Is Initialization (RAII), implemented by means of special \newterm{constructor} and \newterm{destructor} functions; we have implemented a similar feature in \CFA. 1477 1492 While RAII is a common feature of object-oriented programming languages, its inclusion in \CFA does not violate the design principle that \CFA retain the same procedural paradigm as C. 1478 1493 In particular, \CFA does not implement class-based encapsulation: neither the constructor nor any other function has privileged access to the implementation details of a type, except through the translation-unit-scope method of opaque structs provided by C. … … 1506 1521 \end{cfa} 1507 1522 1508 In the example above, a \ emph{default constructor} (\ie one with no parameters besides the @this@ parameter) and destructor are defined for the @Array@ struct, a dynamic array of @int@.1509 @Array@ is an example of a \ emph{managed type} in \CFA, a type with a non-trivial constructor or destructor, or with a field of a managed type.1523 In the example above, a \newterm{default constructor} (\ie one with no parameters besides the @this@ parameter) and destructor are defined for the @Array@ struct, a dynamic array of @int@. 1524 @Array@ is an example of a \newterm{managed type} in \CFA, a type with a non-trivial constructor or destructor, or with a field of a managed type. 1510 1525 As in the example, all instances of managed types are implicitly constructed upon allocation, and destructed upon deallocation; this ensures proper initialization and cleanup of resources contained in managed types, in this case the @data@ array on the heap. 1511 1526 The exact details of the placement of these implicit constructor and destructor calls are omitted here for brevity, the interested reader should consult \cite{Schluntz17}. 1512 1527 1513 1528 Constructor calls are intended to seamlessly integrate with existing C initialization syntax, providing a simple and familiar syntax to veteran C programmers and allowing constructor calls to be inserted into legacy C code with minimal code changes. 1514 As such, \CFA also provides syntax for \ emph{copy initialization} and \emph{initialization parameters}:1529 As such, \CFA also provides syntax for \newterm{copy initialization} and \newterm{initialization parameters}: 1515 1530 1516 1531 \begin{cfa} … … 1527 1542 In addition to initialization syntax, \CFA provides two ways to explicitly call constructors and destructors. 1528 1543 Explicit calls to constructors double as a placement syntax, useful for construction of member fields in user-defined constructors and reuse of large storage allocations. 1529 While the existing function-call syntax works for explicit calls to constructors and destructors, \CFA also provides a more concise \ emph{operator syntax} for both:1544 While the existing function-call syntax works for explicit calls to constructors and destructors, \CFA also provides a more concise \newterm{operator syntax} for both: 1530 1545 1531 1546 \begin{cfa} … … 1544 1559 For compatibility with C, a copy constructor from the first union member type is also defined. 1545 1560 For @struct@ types, each of the four functions are implicitly defined to call their corresponding functions on each member of the struct. 1546 To better simulate the behaviour of C initializers, a set of \ emph{field constructors} is also generated for structures.1561 To better simulate the behaviour of C initializers, a set of \newterm{field constructors} is also generated for structures. 1547 1562 A constructor is generated for each non-empty prefix of a structure's member-list which copy-constructs the members passed as parameters and default-constructs the remaining members. 1548 1563 To allow users to limit the set of constructors available for a type, when a user declares any constructor or destructor, the corresponding generated function and all field constructors for that type are hidden from expression resolution; similarly, the generated default constructor is hidden upon declaration of any constructor. … … 1550 1565 1551 1566 In rare situations user programmers may not wish to have constructors and destructors called; in these cases, \CFA provides an ``escape hatch'' to not call them. 1552 If a variable is initialized using the syntax \lstinline|S x @= {}| it will be an \ emph{unmanaged object}, and will not have constructors or destructors called.1567 If a variable is initialized using the syntax \lstinline|S x @= {}| it will be an \newterm{unmanaged object}, and will not have constructors or destructors called. 1553 1568 Any C initializer can be the right-hand side of an \lstinline|@=| initializer, \eg \lstinline|Array a @= { 0, 0x0 }|, with the usual C initialization semantics. 1554 1569 In addition to the expressive power, \lstinline|@=| provides a simple path for migrating legacy C code to \CFA, by providing a mechanism to incrementally convert initializers; the \CFA design team decided to introduce a new syntax for this escape hatch because we believe that our RAII implementation will handle the vast majority of code in a desirable way, and we wished to maintain familiar syntax for this common case.
Note: See TracChangeset
for help on using the changeset viewer.