- Timestamp:
- Aug 2, 2016, 9:30:34 AM (8 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, ctor, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, memory, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- 155cce0f
- Parents:
- e21c72d (diff), 79f64f1 (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
-
doc/user/user.tex (modified) (37 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/user/user.tex
re21c72d re7b2559 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Wed Jul 13 08:14:39201614 %% Update Count : 12 4713 %% Last Modified On : Mon Aug 1 09:11:24 2016 14 %% Update Count : 1271 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 211 211 however, it largely extended the language, and did not address many existing problems.\footnote{% 212 212 Two important existing problems addressed were changing the type of character literals from ©int© to ©char© and enumerator from ©int© to the type of its enumerators.} 213 \Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features ( e.g.,objects, concurrency) are added and problems fixed within the framework of the existing language.213 \Index*{Fortran}~\cite{Fortran08}, \Index*{Ada}~\cite{Ada12}, and \Index*{Cobol}~\cite{Cobol14} are examples of programming languages that took an evolutionary approach, where modern language features (\eg objects, concurrency) are added and problems fixed within the framework of the existing language. 214 214 \Index*{Java}~\cite{Java8}, \Index*{Go}~\cite{Go}, \Index*{Rust}~\cite{Rust} and \Index*{D}~\cite{D} are examples of the revolutionary approach for modernizing C/\CC, resulting in a new language rather than an extension of the descendent. 215 215 These languages have different syntax and semantics from C, and do not interoperate directly with C, largely because of garbage collection. … … 265 265 \section[Compiling CFA Program]{Compiling \CFA Program} 266 266 267 The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, e.g.:267 The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg: 268 268 \begin{lstlisting} 269 269 cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ] … … 350 350 \section{Underscores in Constants} 351 351 352 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, e.g.:352 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg: 353 353 \begin{lstlisting} 354 354 2®_®147®_®483®_®648; §\C{// decimal constant}§ … … 366 366 \begin{enumerate} 367 367 \item 368 A sequence of underscores is disallowed, e.g.,©12__34© is invalid.368 A sequence of underscores is disallowed, \eg ©12__34© is invalid. 369 369 \item 370 370 Underscores may only appear within a sequence of digits (regardless of the digit radix). 371 In other words, an underscore cannot start or end a sequence of digits, e.g.,©_1©, ©1_© and ©_1_© are invalid (actually, the 1st and 3rd examples are identifier names).371 In other words, an underscore cannot start or end a sequence of digits, \eg ©_1©, ©1_© and ©_1_© are invalid (actually, the 1st and 3rd examples are identifier names). 372 372 \item 373 373 A numeric prefix may end with an underscore; … … 498 498 \end{quote2} 499 499 500 All type qualifiers, e.g., ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, e.g.:500 All type qualifiers, \eg ©const©, ©volatile©, etc., are used in the normal way with the new declarations and also appear left to right, \eg: 501 501 \begin{quote2} 502 502 \begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}} … … 518 518 \end{tabular} 519 519 \end{quote2} 520 All declaration qualifiers, e.g.,©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}521 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}} e.g.:520 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} 521 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: 522 522 \begin{quote2} 523 523 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} … … 542 542 Unsupported are K\&R C declarations where the base type defaults to ©int©, if no type is specified,\footnote{ 543 543 At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each structure declaration and type name~\cite[\S~6.7.2(2)]{C11}} 544 e.g.:544 \eg: 545 545 \begin{lstlisting} 546 546 x; §\C{// int x}§ … … 612 612 A \Index{pointer}/\Index{reference} is a generalization of a variable name, i.e., a mutable address that can point to more than one memory location during its lifetime. 613 613 (Similarly, an integer variable can contain multiple integer literals during its lifetime versus an integer constant representing a single literal during its lifetime and may not occupy storage as the literal is embedded directly into instructions.) 614 Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, e.g.:614 Hence, a pointer occupies memory to store its current address, and the pointer's value is loaded by dereferencing, \eg: 615 615 \begin{quote2} 616 616 \begin{tabular}{@{}ll@{}} … … 669 669 Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example. 670 670 Hence, a reference behaves like the variable name for the current variable it is pointing-to. 671 The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, e.g.:671 The simplest way to understand a reference is to imagine the compiler inserting a dereference operator before the reference variable for each reference qualifier in a declaration, \eg: 672 672 \begin{lstlisting} 673 673 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); … … 677 677 ®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15); 678 678 \end{lstlisting} 679 When a reference operation appears beside a dereference operation, e.g.,©&*©, they cancel out.\footnote{679 When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.\footnote{ 680 680 The unary ©&© operator yields the address of its operand. 681 681 If the operand has type ``type'', the result has type ``pointer to type''. … … 721 721 ®&®crc = &cx; §\C{// error, cannot change crc}§ 722 722 \end{lstlisting} 723 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}, e.g.:723 Hence, for type ©& const©, there is no pointer assignment, so ©&rc = &x© is disallowed, and \emph{the address value cannot be ©0© unless an arbitrary pointer is assigned to the reference}, \eg: 724 724 \begin{lstlisting} 725 725 int & const r = *0; §\C{// where 0 is the int * zero}§ 726 726 \end{lstlisting} 727 727 Otherwise, the compiler is managing the addresses for type ©& const© not the programmer, and by a programming discipline of only using references with references, address errors can be prevented. 728 Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers. 729 The ©const© qualifier cannot be moved before the pointer/reference qualifier for C style-declarations; 730 \CFA-style declarations attempt to address this issue: 731 \begin{quote2} 732 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 733 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 734 \begin{lstlisting} 735 ®const® * ®const® * const int ccp; 736 ®const® & ®const® & const int ccr; 737 \end{lstlisting} 738 & 739 \begin{lstlisting} 740 const int * ®const® * ®const® ccp; 741 742 \end{lstlisting} 743 \end{tabular} 744 \end{quote2} 745 where the \CFA declaration is read left-to-right (see \VRef{s:Declarations}). 728 746 729 747 \Index{Initialization} is different than \Index{assignment} because initialization occurs on the empty (uninitialized) storage on an object, while assignment occurs on possibly initialized storage of an object. … … 785 803 \section{Type Operators} 786 804 787 The new declaration syntax can be used in other contexts where types are required, e.g.,casts and the pseudo-routine ©sizeof©:805 The new declaration syntax can be used in other contexts where types are required, \eg casts and the pseudo-routine ©sizeof©: 788 806 \begin{quote2} 789 807 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} … … 805 823 806 824 \CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax. 807 The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, e.g.:825 The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg: 808 826 \begin{lstlisting} 809 827 ®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) { … … 817 835 \Index*{Michael Tiemann}, with help from \Index*{Doug Lea}, provided named return values in g++, circa 1989.} 818 836 The value of each local return variable is automatically returned at routine termination. 819 Declaration qualifiers can only appear at the start of a routine definition, e.g.:837 Declaration qualifiers can only appear at the start of a routine definition, \eg: 820 838 \begin{lstlisting} 821 839 ®extern® [ int x ] g( int y ) {§\,§} … … 849 867 The inability to use \CFA declarations in these two contexts is probably a blessing because it precludes programmers from arbitrarily switching between declarations forms within a declaration contexts. 850 868 851 C-style declarations can be used to declare parameters for \CFA style routine definitions, e.g.:869 C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg: 852 870 \begin{lstlisting} 853 871 [ int ] f( * int, int * ); §\C{// returns an integer, accepts 2 pointers to integers}§ … … 898 916 899 917 The syntax of the new routine prototype declaration follows directly from the new routine definition syntax; 900 as well, parameter names are optional, e.g.:918 as well, parameter names are optional, \eg: 901 919 \begin{lstlisting} 902 920 [ int x ] f (); §\C{// returning int with no parameters}§ … … 906 924 \end{lstlisting} 907 925 This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa). 908 It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), e.g.:926 It is possible to declare multiple routine-prototypes in a single declaration, but the entire type specification is distributed across \emph{all} routine names in the declaration list (see~\VRef{s:Declarations}), \eg: 909 927 \begin{quote2} 910 928 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} … … 919 937 \end{tabular} 920 938 \end{quote2} 921 Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} e.g.:939 Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg: 922 940 \begin{lstlisting} 923 941 extern [ int ] f (int); … … 928 946 \section{Routine Pointers} 929 947 930 The syntax for pointers to \CFA routines specifies the pointer name on the right, e.g.:948 The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg: 931 949 \begin{lstlisting} 932 950 * [ int x ] () fp; §\C{// pointer to routine returning int with no parameters}§ … … 1046 1064 p( /* positional */, /* named */, . . . ); 1047 1065 \end{lstlisting} 1048 While it is possible to implement both approaches, the first possibly is more complex than the second, e.g.:1066 While it is possible to implement both approaches, the first possibly is more complex than the second, \eg: 1049 1067 \begin{lstlisting} 1050 1068 p( int x, int y, int z, . . . ); … … 1056 1074 In the second call, the named arguments separate the positional and ellipse arguments, making it trivial to read the call. 1057 1075 1058 The problem is exacerbated with default arguments, e.g.:1076 The problem is exacerbated with default arguments, \eg: 1059 1077 \begin{lstlisting} 1060 1078 void p( int x, int y = 2, int z = 3. . . ); … … 1264 1282 1265 1283 As mentioned, tuples can appear in contexts requiring a list of value, such as an argument list of a routine call. 1266 In unambiguous situations, the tuple brackets may be omitted, e.g.,a tuple that appears as an argument may have its1284 In unambiguous situations, the tuple brackets may be omitted, \eg a tuple that appears as an argument may have its 1267 1285 square brackets omitted for convenience; therefore, the following routine invocations are equivalent: 1268 1286 \begin{lstlisting} … … 1303 1321 1304 1322 Type qualifiers, i.e., const and volatile, may modify a tuple type. 1305 The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], i.e., the qualifier is distributed across all of the types in the tuple, e.g.:1323 The meaning is the same as for a type qualifier modifying an aggregate type [Int99, x 6.5.2.3(7),x 6.7.3(11)], i.e., the qualifier is distributed across all of the types in the tuple, \eg: 1306 1324 \begin{lstlisting} 1307 1325 const volatile [ int, float, const int ] x; … … 1311 1329 [ const volatile int, const volatile float, const volatile int ] x; 1312 1330 \end{lstlisting} 1313 Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, e.g.:1331 Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, \eg: 1314 1332 \begin{lstlisting} 1315 1333 extern [ int, int ] w1; … … 1319 1337 Unfortunately, C's syntax for subscripts precluded treating them as tuples. 1320 1338 The C subscript list has the form ©[i][j]...© and not ©[i, j, ...]©. 1321 Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, e.g.,©f[g()]© always means a single subscript value because there is only one set of brackets.1339 Therefore, there is no syntactic way for a routine returning multiple values to specify the different subscript values, \eg ©f[g()]© always means a single subscript value because there is only one set of brackets. 1322 1340 Fixing this requires a major change to C because the syntactic form ©M[i, j, k]© already has a particular meaning: ©i, j, k© is a comma expression. 1323 1341 \end{rationale} … … 1380 1398 Clearly, the types of the entities being assigned must be type compatible with the value of the expression. 1381 1399 1382 Mass assignment has parallel semantics, e.g.,the statement:1400 Mass assignment has parallel semantics, \eg the statement: 1383 1401 \begin{lstlisting} 1384 1402 [ x, y, z ] = 1.5; … … 1469 1487 \section{Unnamed Structure Fields} 1470 1488 1471 C requires each field of a structure to have a name, except for a bit field associated with a basic type, e.g.:1489 C requires each field of a structure to have a name, except for a bit field associated with a basic type, \eg: 1472 1490 \begin{lstlisting} 1473 1491 struct { 1474 int f1; // named field1475 int f2 : 4; // named field with bit field size1476 int : 3; // unnamed field for basic type with bit field size1477 int ; // disallowed, unnamed field1478 int *; // disallowed, unnamed field1479 int (*)(int); // disallowed, unnamed field1492 int f1; §\C{// named field}§ 1493 int f2 : 4; §\C{// named field with bit field size}§ 1494 int : 3; §\C{// unnamed field for basic type with bit field size}§ 1495 int ; §\C{// disallowed, unnamed field}§ 1496 int *; §\C{// disallowed, unnamed field}§ 1497 int (*)(int); §\C{// disallowed, unnamed field}§ 1480 1498 }; 1481 1499 \end{lstlisting} 1482 1500 This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed. 1483 1501 As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size. 1484 A list of unnamed fields is also supported, e.g.:1502 A list of unnamed fields is also supported, \eg: 1485 1503 \begin{lstlisting} 1486 1504 struct { 1487 int , , ; // 3 unnamed fields1505 int , , ; §\C{// 3 unnamed fields}§ 1488 1506 } 1489 1507 \end{lstlisting} … … 1498 1516 §\emph{expr}§ -> [ §\emph{fieldlist}§ ] 1499 1517 \end{lstlisting} 1500 \emph{expr} is any expression yielding a value of type record, e.g.,©struct©, ©union©.1518 \emph{expr} is any expression yielding a value of type record, \eg ©struct©, ©union©. 1501 1519 Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}. 1502 1520 A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is … … 1760 1778 } 1761 1779 \end{lstlisting} 1762 While the declaration of the local variable ©y© is useful and its scope is across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it. 1763 Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©. 1764 As mentioned, transfer into control structures should be forbidden; 1765 transfers from within the ©switch© body using a ©goto© are equally unpalatable. 1766 As well, the declaration of ©z© is cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized. 1780 While the declaration of the local variable ©y© is useful with a scope across all ©case© clauses, the initialization for such a variable is defined to never be executed because control always transfers over it. 1781 Furthermore, any statements before the first ©case© clause can only be executed if labelled and transferred to using a ©goto©, either from outside or inside of the ©switch©, both of which are problematic. 1782 As well, the declaration of ©z© cannot occur after the ©case© because a label can only be attached to a statement, and without a fall through to case 3, ©z© is uninitialized. 1783 The key observation is that the ©switch© statement branches into control structure, i.e., there are multiple entry points into its statement body. 1767 1784 \end{enumerate} 1768 1785 … … 1778 1795 and there is only a medium amount of fall-through from one ©case© clause to the next, and most of these result from a list of case values executing common code, rather than a sequence of case actions that compound. 1779 1796 \end{itemize} 1780 These observations help to put the suggestedchanges to the ©switch© into perspective.1797 These observations help to put the \CFA changes to the ©switch© into perspective. 1781 1798 \begin{enumerate} 1782 1799 \item 1783 1800 Eliminating default fall-through has the greatest potential for affecting existing code. 1784 However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, i.e., a list of ©case© clauses executing common code, e.g.:1785 \begin{lstlisting}1801 However, even if fall-through is removed, most ©switch© statements would continue to work because of the explicit transfers already present at the end of each ©case© clause, the common placement of the ©default© clause at the end of the case list, and the most common use of fall-through, i.e., a list of ©case© clauses executing common code, \eg: 1802 \begin{lstlisting} 1786 1803 case 1: case 2: case 3: ... 1787 1804 \end{lstlisting} 1788 1805 still work. 1789 1806 Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments. 1790 Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthru©, e.g.: 1807 <<<<<<< HEAD 1808 Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthru©, \eg: 1809 ======= 1810 Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, e.g.: 1811 >>>>>>> 080615890f586cb9954c252b55cab47f52c25758 1791 1812 \begin{lstlisting} 1792 1813 ®choose® ( i ) { … … 1815 1836 Therefore, no change is made for this issue. 1816 1837 \item 1817 Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause .\footnote{1818 Essentially, these declarations are hoisted before the statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause.1819 Further declaration in the statement body are disallowed.1838 Dealing with unreachable code in a ©switch©/©choose© body is solved by restricting declarations and associated initialization to the start of statement body, which is executed \emph{before} the transfer to the appropriate ©case© clause\footnote{ 1839 Essentially, these declarations are hoisted before the ©switch©/©choose© statement and both declarations and statement are surrounded by a compound statement.} and precluding statements before the first ©case© clause. 1840 Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound. 1820 1841 \begin{lstlisting} 1821 1842 switch ( x ) { 1822 ®int i = 0;® §\C{// allowed }§1843 ®int i = 0;® §\C{// allowed only at start}§ 1823 1844 case 0: 1824 1845 ... 1825 ®int i= 0;® §\C{// disallowed}§1846 ®int j = 0;® §\C{// disallowed}§ 1826 1847 case 1: 1827 1848 { 1828 ®int i = 0;® §\C{// allowed in any compound statement}§1849 ®int k = 0;® §\C{// allowed at different nesting levels}§ 1829 1850 ... 1830 1851 } … … 2707 2728 Like the \Index*[C++]{\CC} lexical problem with closing template-syntax, e.g, ©Foo<Bar<int®>>®©, this issue can be solved with a more powerful lexer/parser. 2708 2729 2709 There are several ambiguous cases with operator identifiers, e.g.,©int *?*?()©, where the string ©*?*?© can be lexed as ©*©/©?*?© or ©*?©/©*?©.2710 Since it is common practise to put a unary operator juxtaposed to an identifier, e.g.,©*i©, users will be annoyed if they cannot do this with respect to operator identifiers.2730 There are several ambiguous cases with operator identifiers, \eg ©int *?*?()©, where the string ©*?*?© can be lexed as ©*©/©?*?© or ©*?©/©*?©. 2731 Since it is common practise to put a unary operator juxtaposed to an identifier, \eg ©*i©, users will be annoyed if they cannot do this with respect to operator identifiers. 2711 2732 Even with this special hack, there are 5 general cases that cannot be handled. 2712 2733 The first case is for the function-call identifier ©?()©: … … 2773 2794 This means that a function requiring mutual exclusion could block if the lock is already held by another thread. 2774 2795 Blocking on a monitor lock does not block the kernel thread, it simply blocks the user thread, which yields its kernel thread while waiting to obtain the lock. 2775 If multiple mutex parameters are specified, they will be locked in parameter order ( i.e.first parameter is locked first) and unlocked in the2796 If multiple mutex parameters are specified, they will be locked in parameter order (\ie first parameter is locked first) and unlocked in the 2776 2797 reverse order. 2777 2798 \begin{lstlisting} … … 4342 4363 4343 4364 4365 \section{New Keywowrds} 4366 4367 ©catch©, ©catchResume©, ©choose©, \quad ©disable©, ©dtype©, \quad ©enable©, \quad ©fallthrough©, ©fallthru©, ©finally©, ©forall©, ©ftype©, \quad ©lvalue©, \quad ©otype©, \quad ©throw©, ©throwResume©, ©trait©, ©try© 4368 4369 4344 4370 \section{Incompatible} 4345 4371 … … 4471 4497 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}. 4472 4498 Nested types are not hoisted and can be referenced using the field selection operator ``©.©'', unlike the \CC scope-resolution operator ``©::©''. 4473 Given that nested types in C are equivalent to not using them, i.e.,they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility.4499 Given that nested types in C are equivalent to not using them, \ie they are essentially useless, it is unlikely there are any realistic usages that break because of this incompatibility. 4474 4500 \end{description} 4475 4501 … … 5162 5188 \label{s:RationalNumbers} 5163 5189 5164 Rational numbers are numbers written as a ratio, i.e.,as a fraction, where the numerator (top number) and the denominator (bottom number) are whole numbers.5190 Rational numbers are numbers written as a ratio, \ie as a fraction, where the numerator (top number) and the denominator (bottom number) are whole numbers. 5165 5191 When creating and computing with rational numbers, results are constantly reduced to keep the numerator and denominator as small as possible. 5166 5192
Note: See TracChangeset
for help on using the changeset viewer.
