Changeset 2264c11
- Timestamp:
- Apr 6, 2017, 10:53:11 AM (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:
- 115a868
- Parents:
- 80cdb2f
- Location:
- doc
- Files:
-
- 3 edited
-
LaTeXmacros/common.tex (modified) (4 diffs)
-
refrat/refrat.tex (modified) (2 diffs)
-
user/user.tex (modified) (259 diffs)
Legend:
- Unmodified
- Added
- Removed
-
doc/LaTeXmacros/common.tex
r80cdb2f r2264c11 11 11 %% Created On : Sat Apr 9 10:06:17 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Fri Feb 10 11:32:36201714 %% Update Count : 2 4913 %% Last Modified On : Wed Apr 5 23:19:42 2017 14 %% Update Count : 255 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 256 256 }% 257 257 258 \newcommand{\CFADefault Style}{%258 \newcommand{\CFADefaults}{% 259 259 \lstset{ 260 260 language=CFA, … … 267 267 escapechar=§, % LaTeX escape in CFA code §...§ (section symbol), emacs: C-q M-' 268 268 mathescape=true, % LaTeX math escape in CFA code $...$ 269 %keepspaces=true, %269 keepspaces=true, % 270 270 showstringspaces=false, % do not show spaces with cup 271 271 showlines=true, % show blank lines at end of code … … 281 281 moredelim=[is][\lstset{keywords={}}]{¶}{¶}, % keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^ 282 282 }% lstset 283 }% CFADefaults 284 \newcommand{\CFAStyle}{% 285 \CFADefaults 283 286 % inline code ©...© (copyright symbol) emacs: C-q M-) 284 287 \lstMakeShortInline© % single-character for \lstinline 285 }%CFADefaultStyle 288 }% CFAStyle 289 290 \lstnewenvironment{cfa}[1][] 291 {\CFADefaults\lstset{#1}} 292 {} 293 286 294 287 295 % Local Variables: % -
doc/refrat/refrat.tex
r80cdb2f r2264c11 11 11 %% Created On : Wed Apr 6 14:52:25 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Mon Feb 20 13:08:11201714 %% Update Count : 7 813 %% Last Modified On : Wed Apr 5 23:23:28 2017 14 %% Update Count : 79 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 48 48 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 49 49 50 \CFA DefaultStyle% use default CFA format-style50 \CFAStyle % use default CFA format-style 51 51 52 52 % inline code ©...© (copyright symbol) emacs: C-q M-) -
doc/user/user.tex
r80cdb2f r2264c11 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Thu Mar 23 09:53:57201714 %% Update Count : 1 39913 %% Last Modified On : Wed Apr 5 23:19:40 2017 14 %% Update Count : 1412 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 50 50 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 51 51 52 \CFA DefaultStyle% use default CFA format-style52 \CFAStyle % use default CFA format-style 53 53 54 54 % inline code ©...© (copyright symbol) emacs: C-q M-) … … 154 154 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 155 155 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 156 \begin{ lstlisting}156 \begin{cfa} 157 157 #include <fstream> 158 158 int main( void ) { … … 160 160 ®sout | x | y | z | endl;® 161 161 } 162 \end{ lstlisting}162 \end{cfa} 163 163 & 164 164 \begin{lstlisting} … … 245 245 For example, the C math-library provides the following routines for computing the absolute value of the basic types: ©abs©, ©labs©, ©llabs©, ©fabs©, ©fabsf©, ©fabsl©, ©cabsf©, ©cabs©, and ©cabsl©. 246 246 Whereas, \CFA wraps each of these routines into ones with the common name ©abs©: 247 \begin{ lstlisting}247 \begin{cfa} 248 248 char abs( char ); 249 extern "C" { 249 ®extern "C" {® 250 250 int abs( int ); §\C{// use default C routine for int}§ 251 }// extern "C"251 ®}® // extern "C" 252 252 long int abs( long int ); 253 253 long long int abs( long long int ); … … 258 258 double _Complex abs( double _Complex ); 259 259 long double _Complex abs( long double _Complex ); 260 \end{ lstlisting}260 \end{cfa} 261 261 The problem is the name clash between the library routine ©abs© and the \CFA names ©abs©. 262 262 Hence, names appearing in an ©extern "C"© block have \newterm*{C linkage}. … … 273 273 274 274 The command ©cfa© is used to compile \CFA program(s), and is based on the GNU \Indexc{gcc} command, \eg: 275 \begin{ lstlisting}275 \begin{cfa} 276 276 cfa§\indexc{cfa}\index{compilation!cfa@©cfa©}§ [ gcc-options ] C/§\CFA§-files [ assembler/loader-files ] 277 \end{ lstlisting}277 \end{cfa} 278 278 \CFA programs having the following ©gcc© flags turned on: 279 279 \begin{description} … … 352 352 These preprocessor variables allow conditional compilation of programs that must work differently in these situations. 353 353 For example, to toggle between C and \CFA extensions, using the following: 354 \begin{ lstlisting}354 \begin{cfa} 355 355 #ifndef __CFORALL__ 356 356 #include <stdio.h> §\C{// C header file}§ … … 358 358 #include <fstream> §\C{// \CFA header file}§ 359 359 #endif 360 \end{ lstlisting}360 \end{cfa} 361 361 which conditionally includes the correct header file, if the program is compiled using \Indexc{gcc} or \Indexc{cfa}. 362 362 363 363 364 \section{ Underscores in Constants}364 \section{Constants Underscores} 365 365 366 366 Numeric constants are extended to allow \Index{underscore}s within constants\index{constant!underscore}, \eg: 367 \begin{ lstlisting}367 \begin{cfa} 368 368 2®_®147®_®483®_®648; §\C{// decimal constant}§ 369 369 56_ul; §\C{// decimal unsigned long constant}§ … … 376 376 0x_1.ffff_ffff_p_128_l; §\C{// hexadecimal floating point long constant}§ 377 377 L_"\x_ff_ee"; §\C{// wide character constant}§ 378 \end{ lstlisting}378 \end{cfa} 379 379 The rules for placement of underscores is as follows: 380 380 \begin{enumerate} … … 396 396 397 397 398 \section{Backquote Identifiers} 399 \label{s:BackquoteIdentifiers} 400 401 \CFA accommodates keyword clashes by syntactic transformations using the \CFA backquote escape-mechanism: 402 \begin{cfa} 403 int ®`®otype®`® = 3; §\C{// make keyword an identifier}§ 404 double ®`®choose®`® = 3.5; 405 \end{cfa} 406 Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to an non-keyword name. 407 Clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled automatically using the preprocessor, ©#include_next© and ©-I filename©: 408 \begin{cfa} 409 // include file uses the CFA keyword "otype". 410 #if ! defined( otype ) §\C{// nesting ?}§ 411 #define otype `otype` 412 #define __CFA_BFD_H__ 413 #endif // ! otype 414 415 #include_next <bfd.h> §\C{// must have internal check for multiple expansion}§ 416 417 #if defined( otype ) && defined( __CFA_BFD_H__ ) §\C{// reset only if set}§ 418 #undef otype 419 #undef __CFA_BFD_H__ 420 #endif // otype && __CFA_BFD_H__ 421 \end{cfa} 422 423 398 424 \section{Declarations} 399 425 \label{s:Declarations} … … 403 429 \begin{quote2} 404 430 \begin{tabular}{@{}ll@{}} 405 \begin{ lstlisting}431 \begin{cfa} 406 432 int *x[5] 407 \end{ lstlisting}433 \end{cfa} 408 434 & 409 435 \raisebox{-0.75\totalheight}{\input{Cdecl}} … … 414 440 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. 415 441 For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way: 416 \begin{ lstlisting}442 \begin{cfa} 417 443 int (*f())[5] {...}; §\C{}§ 418 444 ... (*f())[3] += 1; 419 \end{ lstlisting}445 \end{cfa} 420 446 Essentially, the return type is wrapped around the routine name in successive layers (like an onion). 421 447 While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice. … … 428 454 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 429 455 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 430 \begin{ lstlisting}456 \begin{cfa} 431 457 ß[5] *ß ®int® x1; 432 458 ß* [5]ß ®int® x2; 433 459 ß[* [5] int]ß f®( int p )®; 434 \end{ lstlisting}460 \end{cfa} 435 461 & 436 \begin{ lstlisting}462 \begin{cfa} 437 463 ®int® ß*ß x1 ß[5]ß; 438 464 ®int® ß(*ßx2ß)[5]ß; 439 465 ßint (*ßf®( int p )®ß)[5]ß; 440 \end{ lstlisting}466 \end{cfa} 441 467 \end{tabular} 442 468 \end{quote2} … … 448 474 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 449 475 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 450 \begin{ lstlisting}476 \begin{cfa} 451 477 ®*® int x, y; 452 \end{ lstlisting}478 \end{cfa} 453 479 & 454 \begin{ lstlisting}480 \begin{cfa} 455 481 int ®*®x, ®*®y; 456 \end{ lstlisting}482 \end{cfa} 457 483 \end{tabular} 458 484 \end{quote2} … … 461 487 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 462 488 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 463 \begin{ lstlisting}489 \begin{cfa} 464 490 ®*® int x; 465 491 int y; 466 \end{ lstlisting}492 \end{cfa} 467 493 & 468 \begin{ lstlisting}494 \begin{cfa} 469 495 int ®*®x, y; 470 496 471 \end{ lstlisting}497 \end{cfa} 472 498 \end{tabular} 473 499 \end{quote2} … … 477 503 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} 478 504 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ 479 \begin{ lstlisting}505 \begin{cfa} 480 506 [ 5 ] int z; 481 507 [ 5 ] * char w; … … 486 512 [ 5 ] * int f2; 487 513 }; 488 \end{ lstlisting}514 \end{cfa} 489 515 & 490 \begin{ lstlisting}516 \begin{cfa} 491 517 int z[ 5 ]; 492 518 char *w[ 5 ]; … … 497 523 int *f2[ 5 ] 498 524 }; 499 \end{ lstlisting}525 \end{cfa} 500 526 & 501 \begin{ lstlisting}527 \begin{cfa} 502 528 // array of 5 integers 503 529 // array of 5 pointers to char … … 508 534 509 535 510 \end{ lstlisting}536 \end{cfa} 511 537 \end{tabular} 512 538 \end{quote2} … … 516 542 \begin{tabular}{@{}l@{\hspace{1em}}l@{\hspace{1em}}l@{}} 517 543 \multicolumn{1}{c@{\hspace{1em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{1em}}}{\textbf{C}} \\ 518 \begin{ lstlisting}544 \begin{cfa} 519 545 const * const int x; 520 546 const * [ 5 ] const int y; 521 \end{ lstlisting}547 \end{cfa} 522 548 & 523 \begin{ lstlisting}549 \begin{cfa} 524 550 int const * const x; 525 551 const int (* const y)[ 5 ] 526 \end{ lstlisting}552 \end{cfa} 527 553 & 528 \begin{ lstlisting}554 \begin{cfa} 529 555 // const pointer to const integer 530 556 // const pointer to array of 5 const integers 531 \end{ lstlisting}557 \end{cfa} 532 558 \end{tabular} 533 559 \end{quote2} … … 537 563 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} 538 564 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ 539 \begin{ lstlisting}565 \begin{cfa} 540 566 extern [ 5 ] int x; 541 567 static * const int y; 542 \end{ lstlisting}568 \end{cfa} 543 569 & 544 \begin{ lstlisting}570 \begin{cfa} 545 571 int extern x[ 5 ]; 546 572 const int static *y; 547 \end{ lstlisting}573 \end{cfa} 548 574 & 549 \begin{ lstlisting}575 \begin{cfa} 550 576 // externally visible array of 5 integers 551 577 // internally visible pointer to constant int 552 \end{ lstlisting}578 \end{cfa} 553 579 \end{tabular} 554 580 \end{quote2} … … 557 583 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}} 558 584 \eg: 559 \begin{ lstlisting}585 \begin{cfa} 560 586 x; §\C{// int x}§ 561 587 *y; §\C{// int *y}§ 562 588 f( p1, p2 ); §\C{// int f( int p1, int p2 );}§ 563 589 f( p1, p2 ) {} §\C{// int f( int p1, int p2 ) {}}§ 564 \end{ lstlisting}590 \end{cfa} 565 591 566 592 Finally, new \CFA declarations may appear together with C declarations in the same program block, but cannot be mixed within a specific declaration. … … 583 609 \begin{quote2} 584 610 \begin{tabular}{@{}lll@{}} 585 \begin{ lstlisting}611 \begin{cfa} 586 612 int x; 587 613 x = 3; 588 614 int y; 589 615 y = x; 590 \end{ lstlisting}616 \end{cfa} 591 617 & 592 618 \raisebox{-0.45\totalheight}{\input{pointer1}} 593 619 & 594 \begin{ lstlisting}620 \begin{cfa} 595 621 int * ®const® x = (int *)100 596 622 *x = 3; // implicit dereference 597 623 int * ®const® y = (int *)104; 598 624 *y = *x; // implicit dereference 599 \end{ lstlisting}625 \end{cfa} 600 626 \end{tabular} 601 627 \end{quote2} … … 606 632 \begin{quote2} 607 633 \begin{tabular}{@{}l|l@{}} 608 \begin{ lstlisting}634 \begin{cfa} 609 635 lda r1,100 // load address of x 610 636 ld r2,(r1) // load value of x 611 637 lda r3,104 // load address of y 612 638 st r2,(r3) // store x into y 613 \end{ lstlisting}639 \end{cfa} 614 640 & 615 \begin{ lstlisting}641 \begin{cfa} 616 642 617 643 ld r2,(100) // load value of x 618 644 619 645 st r2,(104) // store x into y 620 \end{ lstlisting}646 \end{cfa} 621 647 \end{tabular} 622 648 \end{quote2} … … 629 655 \begin{quote2} 630 656 \begin{tabular}{@{}ll@{}} 631 \begin{ lstlisting}657 \begin{cfa} 632 658 int x, y, ®*® p1, ®*® p2, ®**® p3; 633 659 p1 = ®&®x; // p1 points to x … … 635 661 p1 = ®&®y; // p1 points to y 636 662 p3 = &p2; // p3 points to p2 637 \end{ lstlisting}663 \end{cfa} 638 664 & 639 665 \raisebox{-0.45\totalheight}{\input{pointer2.pstex_t}} … … 643 669 Notice, an address has a duality\index{address!duality}: a location in memory or the value at that location. 644 670 In many cases, a compiler might be able to infer the meaning: 645 \begin{ lstlisting}671 \begin{cfa} 646 672 p2 = p1 + x; §\C{// compiler infers *p2 = *p1 + x;}§ 647 \end{ lstlisting}673 \end{cfa} 648 674 because adding the arbitrary integer value in ©x© to the address of ©p1© and storing the resulting address into ©p2© is an unlikely operation. 649 675 \Index*{Algol68}~\cite{Algol68} inferences pointer dereferencing to select the best meaning for each pointer usage. 650 676 However, in C, the following cases are ambiguous, especially with pointer arithmetic: 651 \begin{ lstlisting}677 \begin{cfa} 652 678 p1 = p2; §\C{// p1 = p2\ \ or\ \ *p1 = *p2}§ 653 679 p1 = p1 + 1; §\C{// p1 = p1 + 1\ \ or\ \ *p1 = *p1 + 1}§ 654 \end{ lstlisting}680 \end{cfa} 655 681 656 682 Most languages pick one meaning as the default and the programmer explicitly indicates the other meaning to resolve the address-duality ambiguity\index{address! ambiguity}. 657 683 In C, the default meaning for pointers is to manipulate the pointer's address and the pointed-to value is explicitly accessed by the dereference operator ©*©. 658 \begin{ lstlisting}684 \begin{cfa} 659 685 p1 = p2; §\C{// pointer address assignment}§ 660 686 *p1 = *p1 + 1; §\C{// pointed-to value assignment / operation}§ 661 \end{ lstlisting}687 \end{cfa} 662 688 which works well for situations where manipulation of addresses is the primary meaning and data is rarely accessed, such as storage management (©malloc©/©free©). 663 689 664 690 However, in most other situations, the pointed-to value is requested more often than the pointer address. 665 \begin{ lstlisting}691 \begin{cfa} 666 692 *p2 = ((*p1 + *p2) * (**p3 - *p1)) / (**p3 - 15); 667 \end{ lstlisting}693 \end{cfa} 668 694 In this case, it is tedious to explicitly write the dereferencing, and error prone when pointer arithmetic is allowed. 669 695 It is better to have the compiler generate the dereferencing and have no implicit pointer arithmetic: 670 \begin{ lstlisting}696 \begin{cfa} 671 697 p2 = ((p1 + p2) * (p3 - p1)) / (p3 - 15); 672 \end{ lstlisting}698 \end{cfa} 673 699 674 700 To switch the default meaning for an address requires a new kind of pointer, called a \newterm{reference} denoted by ©&©. 675 \begin{ lstlisting}701 \begin{cfa} 676 702 int x, y, ®&® r1, ®&® r2, ®&&® r3; 677 703 ®&®r1 = &x; §\C{// r1 points to x}§ … … 680 706 ®&&®r3 = ®&®&r2; §\C{// r3 points to r2}§ 681 707 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); §\C{// implicit dereferencing}§ 682 \end{ lstlisting}708 \end{cfa} 683 709 Except for auto-dereferencing by the compiler, this reference example is the same as the previous pointer example. 684 710 Hence, a reference behaves like the variable name for the current variable it is pointing-to. 685 711 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: 686 \begin{ lstlisting}712 \begin{cfa} 687 713 r2 = ((r1 + r2) * (r3 - r1)) / (r3 - 15); 688 \end{ lstlisting}714 \end{cfa} 689 715 is rewritten as: 690 \begin{ lstlisting}716 \begin{cfa} 691 717 ®*®r2 = ((®*®r1 + ®*®r2) ®*® (®**®r3 - ®*®r1)) / (®**®r3 - 15); 692 \end{ lstlisting}718 \end{cfa} 693 719 When a reference operation appears beside a dereference operation, \eg ©&*©, they cancel out.\footnote{ 694 720 The unary ©&© operator yields the address of its operand. … … 696 722 If the operand is the result of a unary ©*© operator, neither that operator nor the ©&© operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.~\cite[\S~6.5.3.2--3]{C11}} 697 723 Hence, assigning to a reference requires the address of the reference variable (\Index{lvalue}): 698 \begin{ lstlisting}724 \begin{cfa} 699 725 (&®*®)r1 = &x; §\C{// (\&*) cancel giving variable r1 not variable pointed-to by r1}§ 700 \end{ lstlisting}726 \end{cfa} 701 727 Similarly, the address of a reference can be obtained for assignment or computation (\Index{rvalue}): 702 \begin{ lstlisting}728 \begin{cfa} 703 729 (&(&®*®)®*®)r3 = &(&®*®)r2; §\C{// (\&*) cancel giving address of r2, (\&(\&*)*) cancel giving variable r3}§ 704 \end{ lstlisting}730 \end{cfa} 705 731 Cancellation\index{cancellation!pointer/reference}\index{pointer!cancellation} works to arbitrary depth, and pointer and reference values are interchangeable because both contain addresses. 706 \begin{ lstlisting}732 \begin{cfa} 707 733 int x, *p1 = &x, **p2 = &p1, ***p3 = &p2, 708 734 &r1 = x, &&r2 = r1, &&&r3 = r2; … … 714 740 &&r3 = ...; §\C{// change r2, (\&(\&*)*)*r3, 2 cancellations}§ 715 741 &&&r3 = p3; §\C{// change r3 to p3, (\&(\&(\&*)*)*)r3, 3 cancellations}§ 716 \end{ lstlisting}742 \end{cfa} 717 743 Finally, implicit dereferencing and cancellation are a static (compilation) phenomenon not a dynamic one. 718 744 That is, all implicit dereferencing and any cancellation is carried out prior to the start of the program, so reference performance is equivalent to pointer performance. … … 724 750 725 751 As for a pointer, a reference may have qualifiers: 726 \begin{ lstlisting}752 \begin{cfa} 727 753 const int cx = 5; §\C{// cannot change cx;}§ 728 754 const int & cr = cx; §\C{// cannot change what cr points to}§ … … 734 760 crc = 7; §\C{// error, cannot change cx}§ 735 761 ®&®crc = &cx; §\C{// error, cannot change crc}§ 736 \end{ lstlisting}762 \end{cfa} 737 763 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: 738 \begin{ lstlisting}764 \begin{cfa} 739 765 int & const r = *0; §\C{// where 0 is the int * zero}§ 740 \end{ lstlisting}766 \end{cfa} 741 767 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. 742 768 Finally, the position of the ©const© qualifier \emph{after} the pointer/reference qualifier causes confuse for C programmers. … … 746 772 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 747 773 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 748 \begin{ lstlisting}774 \begin{cfa} 749 775 ®const® * ®const® * const int ccp; 750 776 ®const® & ®const® & const int ccr; 751 \end{ lstlisting}777 \end{cfa} 752 778 & 753 \begin{ lstlisting}779 \begin{cfa} 754 780 const int * ®const® * ®const® ccp; 755 781 756 \end{ lstlisting}782 \end{cfa} 757 783 \end{tabular} 758 784 \end{quote2} … … 762 788 There are three initialization contexts in \CFA: declaration initialization, argument/parameter binding, return/temporary binding. 763 789 For reference initialization (like pointer), the initializing value must be an address (\Index{lvalue}) not a value (\Index{rvalue}). 764 \begin{ lstlisting}790 \begin{cfa} 765 791 int * p = &x; §\C{// both \&x and x are possible interpretations}§ 766 792 int & r = x; §\C{// x unlikely interpretation, because of auto-dereferencing}§ 767 \end{ lstlisting}793 \end{cfa} 768 794 Hence, the compiler implicitly inserts a reference operator, ©&©, before the initialization expression. 769 795 Similarly, when a reference is used for a parameter/return type, the call-site argument does not require a reference operator. 770 \begin{ lstlisting}796 \begin{cfa} 771 797 int & f( int & rp ); §\C{// reference parameter and return}§ 772 798 z = f( x ) + f( y ); §\C{// reference operator added, temporaries needed for call results}§ 773 \end{ lstlisting}799 \end{cfa} 774 800 Within routine ©f©, it is possible to change the argument by changing the corresponding parameter, and parameter ©rp© can be locally reassigned within ©f©. 775 801 Since ©?+?© takes its arguments by value, the references returned from ©f© are used to initialize compiler generated temporaries with value semantics that copy from the references. 776 802 777 803 When a pointer/reference parameter has a ©const© value (immutable), it is possible to pass literals and expressions. 778 \begin{ lstlisting}804 \begin{cfa} 779 805 void f( ®const® int & crp ); 780 806 void g( ®const® int * cpp ); 781 807 f( 3 ); g( &3 ); 782 808 f( x + y ); g( &(x + y) ); 783 \end{ lstlisting}809 \end{cfa} 784 810 Here, the compiler passes the address to the literal 3 or the temporary for the expression ©x + y©, knowing the argument cannot be changed through the parameter. 785 811 (The ©&© is necessary for the pointer parameter to make the types match, and is a common requirement for a C programmer.) 786 812 \CFA \emph{extends} this semantics to a mutable pointer/reference parameter, and the compiler implicitly creates the necessary temporary (copying the argument), which is subsequently pointed-to by the reference parameter and can be changed. 787 \begin{ lstlisting}813 \begin{cfa} 788 814 void f( int & rp ); 789 815 void g( int * pp ); 790 816 f( 3 ); g( &3 ); §\C{// compiler implicit generates temporaries}§ 791 817 f( x + y ); g( &(x + y) ); §\C{// compiler implicit generates temporaries}§ 792 \end{ lstlisting}818 \end{cfa} 793 819 Essentially, there is an implicit \Index{rvalue} to \Index{lvalue} conversion in this case.\footnote{ 794 820 This conversion attempts to address the \newterm{const hell} problem, when the innocent addition of a ©const© qualifier causes a cascade of type failures, requiring an unknown number of additional ©const© qualifiers, until it is discovered a ©const© qualifier cannot be added and all the ©const© qualifiers must be removed.} … … 796 822 797 823 While \CFA attempts to handle pointers and references in a uniform, symmetric manner, C handles routine variables in an inconsistent way: a routine variable is both a pointer and a reference (particle and wave). 798 \begin{ lstlisting}824 \begin{cfa} 799 825 void f( int p ) {...} 800 826 void (*fp)( int ) = &f; §\C{// pointer initialization}§ … … 802 828 (*fp)(3); §\C{// pointer invocation}§ 803 829 fp(3); §\C{// reference invocation}§ 804 \end{ lstlisting}830 \end{cfa} 805 831 A routine variable is best described by a ©const© reference: 806 \begin{ lstlisting}832 \begin{cfa} 807 833 const void (&fp)( int ) = f; 808 834 fp( 3 ); 809 835 fp = ... §\C{// error, cannot change code}§ 810 836 &fp = ...; §\C{// changing routine reference}§ 811 \end{ lstlisting}837 \end{cfa} 812 838 because the value of the routine variable is a routine literal, i.e., the routine code is normally immutable during execution.\footnote{ 813 839 Dynamic code rewriting is possible but only in special circumstances.} 814 840 \CFA allows this additional use of references for routine variables in an attempt to give a more consistent meaning for them. 815 816 817 \section{Backquote Identifiers}818 \label{s:BackquoteIdentifiers}819 820 \CFA accommodates keyword clashes by syntactic transformations using the \CFA backquote escape-mechanism:821 \begin{lstlisting}822 int `otype` = 3; // make keyword an identifier823 double `choose` = 3.5;824 \end{lstlisting}825 Programs can be converted easily by enclosing keyword identifiers in backquotes, and the backquotes can be removed later when the identifier name is changed to an non-keyword name.826 Clashes in C header files (see~\VRef{s:StandardHeaders}) can be handled automatically using the preprocessor, ©#include_next© and ©-I filename©:827 \begin{lstlisting}828 // include file uses the CFA keyword "otype".829 #if ! defined( otype ) // nesting ?830 #define otype `otype`831 #define __CFA_BFD_H__832 #endif // ! otype833 834 #include_next <bfd.h> // must have internal check for multiple expansion835 836 #if defined( otype ) && defined( __CFA_BFD_H__ ) // reset only if set837 #undef otype838 #undef __CFA_BFD_H__839 #endif // otype && __CFA_BFD_H__840 \end{lstlisting}841 841 842 842 … … 847 847 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 848 848 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 849 \begin{ lstlisting}849 \begin{cfa} 850 850 y = (®* int®)x; 851 851 i = sizeof(®[ 5 ] * int®); 852 \end{ lstlisting}852 \end{cfa} 853 853 & 854 \begin{ lstlisting}854 \begin{cfa} 855 855 y = (®int *®)x; 856 856 i = sizeof(®int *[ 5 ]®); 857 \end{ lstlisting}857 \end{cfa} 858 858 \end{tabular} 859 859 \end{quote2} … … 864 864 \CFA also supports a new syntax for routine definition, as well as ISO C and K\&R routine syntax. 865 865 The point of the new syntax is to allow returning multiple values from a routine~\cite{Galletly96,CLU}, \eg: 866 \begin{ lstlisting}866 \begin{cfa} 867 867 ®[ int o1, int o2, char o3 ]® f( int i1, char i2, char i3 ) { 868 868 §\emph{routine body}§ 869 869 } 870 \end{ lstlisting}870 \end{cfa} 871 871 where routine ©f© has three output (return values) and three input parameters. 872 872 Existing C syntax cannot be extended with multiple return types because it is impossible to embed a single routine name within multiple return type specifications. … … 876 876 The value of each local return variable is automatically returned at routine termination. 877 877 Declaration qualifiers can only appear at the start of a routine definition, \eg: 878 \begin{ lstlisting}878 \begin{cfa} 879 879 ®extern® [ int x ] g( int y ) {§\,§} 880 \end{ lstlisting}880 \end{cfa} 881 881 Lastly, if there are no output parameters or input parameters, the brackets and/or parentheses must still be specified; 882 882 in both cases the type is assumed to be void as opposed to old style C defaults of int return type and unknown parameter types, respectively, as in: 883 \begin{ lstlisting}883 \begin{cfa} 884 884 [§\,§] g(); §\C{// no input or output parameters}§ 885 885 [ void ] g( void ); §\C{// no input or output parameters}§ 886 \end{ lstlisting}886 \end{cfa} 887 887 888 888 Routine f is called as follows: 889 \begin{ lstlisting}889 \begin{cfa} 890 890 [ i, j, ch ] = f( 3, 'a', ch ); 891 \end{ lstlisting}891 \end{cfa} 892 892 The list of return values from f and the grouping on the left-hand side of the assignment is called a \newterm{return list} and discussed in Section 12. 893 893 894 894 \CFA style declarations cannot be used to declare parameters for K\&R style routine definitions because of the following ambiguity: 895 \begin{ lstlisting}895 \begin{cfa} 896 896 int (*f(x))[ 5 ] int x; {} 897 \end{ lstlisting}897 \end{cfa} 898 898 The string ``©int (*f(x))[ 5 ]©'' declares a K\&R style routine of type returning a pointer to an array of 5 integers, while the string ``©[ 5 ] int x©'' declares a \CFA style parameter x of type array of 5 integers. 899 899 Since the strings overlap starting with the open bracket, ©[©, there is an ambiguous interpretation for the string. 900 900 As well, \CFA-style declarations cannot be used to declare parameters for C-style routine-definitions because of the following ambiguity: 901 \begin{ lstlisting}901 \begin{cfa} 902 902 typedef int foo; 903 903 int f( int (* foo) ); §\C{// foo is redefined as a parameter name}§ 904 \end{ lstlisting}904 \end{cfa} 905 905 The string ``©int (* foo)©'' declares a C-style named-parameter of type pointer to an integer (the parenthesis are superfluous), while the same string declares a \CFA style unnamed parameter of type routine returning integer with unnamed parameter of type pointer to foo. 906 906 The redefinition of a type name in a parameter list is the only context in C where the character ©*© can appear to the left of a type name, and \CFA relies on all type qualifier characters appearing to the right of the type name. … … 908 908 909 909 C-style declarations can be used to declare parameters for \CFA style routine definitions, \eg: 910 \begin{ lstlisting}910 \begin{cfa} 911 911 [ int ] f( * int, int * ); §\C{// returns an integer, accepts 2 pointers to integers}§ 912 912 [ * int, int * ] f( int ); §\C{// returns 2 pointers to integers, accepts an integer}§ 913 \end{ lstlisting}913 \end{cfa} 914 914 The reason for allowing both declaration styles in the new context is for backwards compatibility with existing preprocessor macros that generate C-style declaration-syntax, as in: 915 \begin{ lstlisting}915 \begin{cfa} 916 916 #define ptoa( n, d ) int (*n)[ d ] 917 917 int f( ptoa( p, 5 ) ) ... §\C{// expands to int f( int (*p)[ 5 ] )}§ 918 918 [ int ] f( ptoa( p, 5 ) ) ... §\C{// expands to [ int ] f( int (*p)[ 5 ] )}§ 919 \end{ lstlisting}919 \end{cfa} 920 920 Again, programmers are highly encouraged to use one declaration form or the other, rather than mixing the forms. 921 921 … … 924 924 925 925 \Index{Named return values} handle the case where it is necessary to define a local variable whose value is then returned in a ©return© statement, as in: 926 \begin{ lstlisting}926 \begin{cfa} 927 927 int f() { 928 928 int x; … … 930 930 return x; 931 931 } 932 \end{ lstlisting}932 \end{cfa} 933 933 Because the value in the return variable is automatically returned when a \CFA routine terminates, the ©return© statement \emph{does not} contain an expression, as in: 934 934 \newline 935 935 \begin{minipage}{\linewidth} 936 \begin{ lstlisting}936 \begin{cfa} 937 937 ®[ int x, int y ]® f() { 938 938 int z; … … 940 940 ®return;® §\C{// implicitly return x, y}§ 941 941 } 942 \end{ lstlisting}942 \end{cfa} 943 943 \end{minipage} 944 944 \newline 945 945 When the return is encountered, the current values of ©x© and ©y© are returned to the calling routine. 946 946 As well, ``falling off the end'' of a routine without a ©return© statement is permitted, as in: 947 \begin{ lstlisting}947 \begin{cfa} 948 948 [ int x, int y ] f() { 949 949 ... 950 950 } §\C{// implicitly return x, y}§ 951 \end{ lstlisting}951 \end{cfa} 952 952 In this case, the current values of ©x© and ©y© are returned to the calling routine just as if a ©return© had been encountered. 953 953 … … 957 957 The syntax of the new routine prototype declaration follows directly from the new routine definition syntax; 958 958 as well, parameter names are optional, \eg: 959 \begin{ lstlisting}959 \begin{cfa} 960 960 [ int x ] f (); §\C{// returning int with no parameters}§ 961 961 [ * int ] g (int y); §\C{// returning pointer to int with int parameter}§ 962 962 [ ] h (int,char); §\C{// returning no result with int and char parameters}§ 963 963 [ * int,int ] j (int); §\C{// returning pointer to int and int, with int parameter}§ 964 \end{ lstlisting}964 \end{cfa} 965 965 This syntax allows a prototype declaration to be created by cutting and pasting source text from the routine definition header (or vice versa). 966 966 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: … … 968 968 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 969 969 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 970 \begin{ lstlisting}970 \begin{cfa} 971 971 [ int ] f(int), g; 972 \end{ lstlisting}972 \end{cfa} 973 973 & 974 \begin{ lstlisting}974 \begin{cfa} 975 975 int f(int), g(int); 976 \end{ lstlisting}976 \end{cfa} 977 977 \end{tabular} 978 978 \end{quote2} 979 979 Declaration qualifiers can only appear at the start of a \CFA routine declaration,\footref{StorageClassSpecifier} \eg: 980 \begin{ lstlisting}980 \begin{cfa} 981 981 extern [ int ] f (int); 982 982 static [ int ] g (int); 983 \end{ lstlisting}983 \end{cfa} 984 984 985 985 … … 987 987 988 988 The syntax for pointers to \CFA routines specifies the pointer name on the right, \eg: 989 \begin{ lstlisting}989 \begin{cfa} 990 990 * [ int x ] () fp; §\C{// pointer to routine returning int with no parameters}§ 991 991 * [ * int ] (int y) gp; §\C{// pointer to routine returning pointer to int with int parameter}§ 992 992 * [ ] (int,char) hp; §\C{// pointer to routine returning no result with int and char parameters}§ 993 993 * [ * int,int ] (int) jp; §\C{// pointer to routine returning pointer to int and int, with int parameter}§ 994 \end{ lstlisting}994 \end{cfa} 995 995 While parameter names are optional, \emph{a routine name cannot be specified}; 996 996 for example, the following is incorrect: 997 \begin{ lstlisting}997 \begin{cfa} 998 998 * [ int x ] f () fp; §\C{// routine name "f" is not allowed}§ 999 \end{ lstlisting}999 \end{cfa} 1000 1000 1001 1001 … … 1010 1010 provide the ability to specify an argument to a routine call using the parameter name rather than the position of the parameter. 1011 1011 For example, given the routine: 1012 \begin{ lstlisting}1012 \begin{cfa} 1013 1013 void p( int x, int y, int z ) {...} 1014 \end{ lstlisting}1014 \end{cfa} 1015 1015 a positional call is: 1016 \begin{ lstlisting}1016 \begin{cfa} 1017 1017 p( 4, 7, 3 ); 1018 \end{ lstlisting}1018 \end{cfa} 1019 1019 whereas a named (keyword) call may be: 1020 \begin{ lstlisting}1020 \begin{cfa} 1021 1021 p( z : 3, x : 4, y : 7 ); §\C{// rewrite $\Rightarrow$ p( 4, 7, 3 )}§ 1022 \end{ lstlisting}1022 \end{cfa} 1023 1023 Here the order of the arguments is unimportant, and the names of the parameters are used to associate argument values with the corresponding parameters. 1024 1024 The compiler rewrites a named call into a positional call. … … 1035 1035 Unfortunately, named arguments do not work in C-style programming-languages because a routine prototype is not required to specify parameter names, nor do the names in the prototype have to match with the actual definition. 1036 1036 For example, the following routine prototypes and definition are all valid. 1037 \begin{ lstlisting}1037 \begin{cfa} 1038 1038 void p( int, int, int ); §\C{// equivalent prototypes}§ 1039 1039 void p( int x, int y, int z ); … … 1041 1041 void p( int z, int y, int x ); 1042 1042 void p( int q, int r, int s ) {} §\C{// match with this definition}§ 1043 \end{ lstlisting}1043 \end{cfa} 1044 1044 Forcing matching parameter names in routine prototypes with corresponding routine definitions is possible, but goes against a strong tradition in C programming. 1045 1045 Alternatively, prototype definitions can be eliminated by using a two-pass compilation, and implicitly creating header files for exports. … … 1048 1048 Furthermore, named arguments do not work well in a \CFA-style programming-languages because they potentially introduces a new criteria for type matching. 1049 1049 For example, it is technically possible to disambiguate between these two overloaded definitions of ©f© based on named arguments at the call site: 1050 \begin{ lstlisting}1050 \begin{cfa} 1051 1051 int f( int i, int j ); 1052 1052 int f( int x, double y ); … … 1055 1055 f( x : 7, y : 8.1 ); §\C{// 2nd f}§ 1056 1056 f( 4, 5 ); §\C{// ambiguous call}§ 1057 \end{ lstlisting}1057 \end{cfa} 1058 1058 However, named arguments compound routine resolution in conjunction with conversions: 1059 \begin{ lstlisting}1059 \begin{cfa} 1060 1060 f( i : 3, 5.7 ); §\C{// ambiguous call ?}§ 1061 \end{ lstlisting}1061 \end{cfa} 1062 1062 Depending on the cost associated with named arguments, this call could be resolvable or ambiguous. 1063 1063 Adding named argument into the routine resolution algorithm does not seem worth the complexity. … … 1067 1067 provide the ability to associate a default value with a parameter so it can be optionally specified in the argument list. 1068 1068 For example, given the routine: 1069 \begin{ lstlisting}1069 \begin{cfa} 1070 1070 void p( int x = 1, int y = 2, int z = 3 ) {...} 1071 \end{ lstlisting}1071 \end{cfa} 1072 1072 the allowable positional calls are: 1073 \begin{ lstlisting}1073 \begin{cfa} 1074 1074 p(); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ 1075 1075 p( 4 ); §\C{// rewrite $\Rightarrow$ p( 4, 2, 3 )}§ … … 1084 1084 p( , , 4 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 4 )}§ 1085 1085 p( , , ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 3 )}§ 1086 \end{ lstlisting}1086 \end{cfa} 1087 1087 Here the missing arguments are inserted from the default values in the parameter list. 1088 1088 The compiler rewrites missing default values into explicit positional arguments. … … 1106 1106 1107 1107 Default values may only appear in a prototype versus definition context: 1108 \begin{ lstlisting}1108 \begin{cfa} 1109 1109 void p( int x, int y = 2, int z = 3 ); §\C{// prototype: allowed}§ 1110 1110 void p( int, int = 2, int = 3 ); §\C{// prototype: allowed}§ 1111 1111 void p( int x, int y = 2, int z = 3 ) {} §\C{// definition: not allowed}§ 1112 \end{ lstlisting}1112 \end{cfa} 1113 1113 The reason for this restriction is to allow separate compilation. 1114 1114 Multiple prototypes with different default values is an error. … … 1117 1117 Ellipse (``...'') arguments present problems when used with default arguments. 1118 1118 The conflict occurs because both named and ellipse arguments must appear after positional arguments, giving two possibilities: 1119 \begin{ lstlisting}1119 \begin{cfa} 1120 1120 p( /* positional */, ... , /* named */ ); 1121 1121 p( /* positional */, /* named */, ... ); 1122 \end{ lstlisting}1122 \end{cfa} 1123 1123 While it is possible to implement both approaches, the first possibly is more complex than the second, \eg: 1124 \begin{ lstlisting}1124 \begin{cfa} 1125 1125 p( int x, int y, int z, ... ); 1126 1126 p( 1, 4, 5, 6, z : 3, y : 2 ); §\C{// assume p( /* positional */, ... , /* named */ );}§ 1127 1127 p( 1, z : 3, y : 2, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§ 1128 \end{ lstlisting}1128 \end{cfa} 1129 1129 In the first call, it is necessary for the programmer to conceptually rewrite the call, changing named arguments into positional, before knowing where the ellipse arguments begin. 1130 1130 Hence, this approach seems significantly more difficult, and hence, confusing and error prone. … … 1132 1132 1133 1133 The problem is exacerbated with default arguments, \eg: 1134 \begin{ lstlisting}1134 \begin{cfa} 1135 1135 void p( int x, int y = 2, int z = 3... ); 1136 1136 p( 1, 4, 5, 6, z : 3 ); §\C{// assume p( /* positional */, ... , /* named */ );}§ 1137 1137 p( 1, z : 3, 4, 5, 6 ); §\C{// assume p( /* positional */, /* named */, ... );}§ 1138 \end{ lstlisting}1138 \end{cfa} 1139 1139 The first call is an error because arguments 4 and 5 are actually positional not ellipse arguments; 1140 1140 therefore, argument 5 subsequently conflicts with the named argument z : 3. … … 1148 1148 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1149 1149 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{default arguments}} & \multicolumn{1}{c}{\textbf{overloading}} \\ 1150 \begin{ lstlisting}1150 \begin{cfa} 1151 1151 void p( int x, int y = 2, int z = 3 ) {...} 1152 1152 1153 1153 1154 \end{ lstlisting}1154 \end{cfa} 1155 1155 & 1156 \begin{ lstlisting}1156 \begin{cfa} 1157 1157 void p( int x, int y, int z ) {...} 1158 1158 void p( int x ) { p( x, 2, 3 ); } 1159 1159 void p( int x, int y ) { p( x, y, 3 ); } 1160 \end{ lstlisting}1160 \end{cfa} 1161 1161 \end{tabular} 1162 1162 \end{quote2} … … 1164 1164 In general, overloading should only be used over default arguments if the body of the routine is significantly different. 1165 1165 Furthermore, overloading cannot handle accessing default arguments in the middle of a positional list, via a missing argument, such as: 1166 \begin{ lstlisting}1166 \begin{cfa} 1167 1167 p( 1, /* default */, 5 ); §\C{// rewrite $\Rightarrow$ p( 1, 2, 5 )}§ 1168 \end{ lstlisting}1168 \end{cfa} 1169 1169 1170 1170 Given the \CFA restrictions above, both named and default arguments are backwards compatible. … … 1186 1186 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{C Type Nesting}} & \multicolumn{1}{c}{\textbf{C Implicit Hoisting}} & \multicolumn{1}{|c}{\textbf{\CFA}} \\ 1187 1187 \hline 1188 \begin{ lstlisting}1188 \begin{cfa} 1189 1189 struct S { 1190 1190 enum C { R, G, B }; … … 1203 1203 union U u; 1204 1204 } 1205 \end{ lstlisting}1205 \end{cfa} 1206 1206 & 1207 \begin{ lstlisting}1207 \begin{cfa} 1208 1208 enum C { R, G, B }; 1209 1209 union U { int i, j; }; … … 1222 1222 1223 1223 1224 \end{ lstlisting}1224 \end{cfa} 1225 1225 & 1226 \begin{ lstlisting}1226 \begin{cfa} 1227 1227 struct S { 1228 1228 enum C { R, G, B }; … … 1241 1241 union ®S.T.®U u; 1242 1242 } 1243 \end{ lstlisting}1243 \end{cfa} 1244 1244 \end{tabular} 1245 1245 \caption{Type Nesting / Qualification} … … 1254 1254 While \CFA does not provide object programming by putting routines into structures, it does rely heavily on locally nested routines to redefine operations at or close to a call site. 1255 1255 For example, the C quick-sort is wrapped into the following polymorphic \CFA routine: 1256 \begin{ lstlisting}1256 \begin{cfa} 1257 1257 forall( otype T | { int ?<?( T, T ); } ) 1258 1258 void qsort( const T * arr, size_t dimension ); 1259 \end{ lstlisting}1259 \end{cfa} 1260 1260 which can be used to sort in ascending and descending order by locally redefining the less-than operator into greater-than. 1261 \begin{ lstlisting}1261 \begin{cfa} 1262 1262 const unsigned int size = 5; 1263 1263 int ia[size]; … … 1268 1268 qsort( ia, size ); §\C{// sort descending order by local redefinition}§ 1269 1269 } 1270 \end{ lstlisting}1270 \end{cfa} 1271 1271 1272 1272 Nested routines are not first-class, meaning a nested routine cannot be returned if it has references to variables in its enclosing blocks; 1273 1273 the only exception is references to the external block of the translation unit, as these variables persist for the duration of the program. 1274 1274 The following program in undefined in \CFA (and Indexc{gcc}) 1275 \begin{ lstlisting}1275 \begin{cfa} 1276 1276 [* [int]( int )] foo() { §\C{// int (*foo())( int )}§ 1277 1277 int ®i® = 7; … … 1286 1286 sout | fp( 3 ) | endl; 1287 1287 } 1288 \end{ lstlisting}1288 \end{cfa} 1289 1289 because 1290 1290 … … 1298 1298 A list of such elements is called a \newterm{lexical list}. 1299 1299 The general syntax of a lexical list is: 1300 \begin{ lstlisting}1300 \begin{cfa} 1301 1301 [ §\emph{exprlist}§ ] 1302 \end{ lstlisting}1302 \end{cfa} 1303 1303 where ©$\emph{exprlist}$© is a list of one or more expressions separated by commas. 1304 1304 The brackets, ©[]©, allow differentiating between lexical lists and expressions containing the C comma operator. 1305 1305 The following are examples of lexical lists: 1306 \begin{ lstlisting}1306 \begin{cfa} 1307 1307 [ x, y, z ] 1308 1308 [ 2 ] 1309 1309 [ v+w, x*y, 3.14159, f() ] 1310 \end{ lstlisting}1310 \end{cfa} 1311 1311 Tuples are permitted to contain sub-tuples (i.e., nesting), such as ©[ [ 14, 21 ], 9 ]©, which is a 2-element tuple whose first element is itself a tuple. 1312 1312 Note, a tuple is not a record (structure); … … 1318 1318 Tuple variables and types can be used anywhere lists of conventional variables and types can be used. 1319 1319 The general syntax of a tuple type is: 1320 \begin{ lstlisting}1320 \begin{cfa} 1321 1321 [ §\emph{typelist}§ ] 1322 \end{ lstlisting}1322 \end{cfa} 1323 1323 where ©$\emph{typelist}$© is a list of one or more legal \CFA or C type specifications separated by commas, which may include other tuple type specifications. 1324 1324 Examples of tuple types include: 1325 \begin{ lstlisting}1325 \begin{cfa} 1326 1326 [ unsigned int, char ] 1327 1327 [ double, double, double ] 1328 1328 [ * int, int * ] §\C{// mix of CFA and ANSI}§ 1329 1329 [ * [ 5 ] int, * * char, * [ [ int, int ] ] (int, int) ] 1330 \end{ lstlisting}1330 \end{cfa} 1331 1331 Like tuples, tuple types may be nested, such as ©[ [ int, int ], int ]©, which is a 2-element tuple type whose first element is itself a tuple type. 1332 1332 1333 1333 Examples of declarations using tuple types are: 1334 \begin{ lstlisting}1334 \begin{cfa} 1335 1335 [ int, int ] x; §\C{// 2 element tuple, each element of type int}§ 1336 1336 * [ char, char ] y; §\C{// pointer to a 2 element tuple}§ 1337 1337 [ [ int, int ] ] z ([ int, int ]); 1338 \end{ lstlisting}1338 \end{cfa} 1339 1339 The last example declares an external routine that expects a 2 element tuple as an input parameter and returns a 2 element tuple as its result. 1340 1340 … … 1342 1342 In unambiguous situations, the tuple brackets may be omitted, \eg a tuple that appears as an argument may have its 1343 1343 square brackets omitted for convenience; therefore, the following routine invocations are equivalent: 1344 \begin{ lstlisting}1344 \begin{cfa} 1345 1345 f( [ 1, x+2, fred() ] ); 1346 1346 f( 1, x+2, fred() ); 1347 \end{ lstlisting}1347 \end{cfa} 1348 1348 Also, a tuple or a tuple variable may be used to supply all or part of an argument list for a routine expecting multiple input parameters or for a routine expecting a tuple as an input parameter. 1349 1349 For example, the following are all legal: 1350 \begin{ lstlisting}1350 \begin{cfa} 1351 1351 [ int, int ] w1; 1352 1352 [ int, int, int ] w2; … … 1361 1361 g( 1, w1 ); 1362 1362 g( w2 ); 1363 \end{ lstlisting}1363 \end{cfa} 1364 1364 Note, in all cases 3 arguments are supplied even though the syntax may appear to supply less than 3. As mentioned, a 1365 1365 tuple does not have structure like a record; a tuple is simply converted into a list of components. … … 1371 1371 A tuple can contain a C comma expression, provided the expression containing the comma operator is enclosed in parentheses. 1372 1372 For instance, the following tuples are equivalent: 1373 \begin{ lstlisting}1373 \begin{cfa} 1374 1374 [ 1, 3, 5 ] 1375 1375 [ 1, (2, 3), 5 ] 1376 \end{ lstlisting}1376 \end{cfa} 1377 1377 The second element of the second tuple is the expression (2, 3), which yields the result 3. 1378 1378 This requirement is the same as for comma expressions in argument lists. … … 1380 1380 Type qualifiers, i.e., const and volatile, may modify a tuple type. 1381 1381 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: 1382 \begin{ lstlisting}1382 \begin{cfa} 1383 1383 const volatile [ int, float, const int ] x; 1384 \end{ lstlisting}1384 \end{cfa} 1385 1385 is equivalent to: 1386 \begin{ lstlisting}1386 \begin{cfa} 1387 1387 [ const volatile int, const volatile float, const volatile int ] x; 1388 \end{ lstlisting}1388 \end{cfa} 1389 1389 Declaration qualifiers can only appear at the start of a \CFA tuple declaration4, \eg: 1390 \begin{ lstlisting}1390 \begin{cfa} 1391 1391 extern [ int, int ] w1; 1392 1392 static [ int, int, int ] w2; 1393 \end{ lstlisting}1393 \end{cfa} 1394 1394 \begin{rationale} 1395 1395 Unfortunately, C's syntax for subscripts precluded treating them as tuples. … … 1405 1405 In addition, the coercion of dereferencing can be performed on a tuple variable to yield its value(s), as for other variables. 1406 1406 A \newterm{closing coercion} takes a set of values and converts it into a tuple value, which is a contiguous set of values, as in: 1407 \begin{ lstlisting}1407 \begin{cfa} 1408 1408 [ int, int, int, int ] w; 1409 1409 w = [ 1, 2, 3, 4 ]; 1410 \end{ lstlisting}1410 \end{cfa} 1411 1411 First the right-hand tuple is closed into a tuple value and then the tuple value is assigned. 1412 1412 1413 1413 An \newterm{opening coercion} is the opposite of closing; a tuple value is converted into a tuple of values, as in: 1414 \begin{ lstlisting}1414 \begin{cfa} 1415 1415 [ a, b, c, d ] = w 1416 \end{ lstlisting}1416 \end{cfa} 1417 1417 ©w© is implicitly opened to yield a tuple of four values, which are then assigned individually. 1418 1418 1419 1419 A \newterm{flattening coercion} coerces a nested tuple, i.e., a tuple with one or more components, which are themselves tuples, into a flattened tuple, which is a tuple whose components are not tuples, as in: 1420 \begin{ lstlisting}1420 \begin{cfa} 1421 1421 [ a, b, c, d ] = [ 1, [ 2, 3 ], 4 ]; 1422 \end{ lstlisting}1422 \end{cfa} 1423 1423 First the right-hand tuple is flattened and then the values are assigned individually. 1424 1424 Flattening is also performed on tuple types. … … 1429 1429 For example, structuring the tuple ©[ 1, 2, 3, 4 ]© into the tuple ©[ 1, [ 2, 3 ], 4 ]© or the tuple type ©[ int, int, int, int ]© into the tuple type ©[ int, [ int, int ], int ]©. 1430 1430 In the following example, the last assignment illustrates all the tuple coercions: 1431 \begin{ lstlisting}1431 \begin{cfa} 1432 1432 [ int, int, int, int ] w = [ 1, 2, 3, 4 ]; 1433 1433 int x = 5; 1434 1434 [ x, w ] = [ w, x ]; §\C{// all four tuple coercions}§ 1435 \end{ lstlisting}1435 \end{cfa} 1436 1436 Starting on the right-hand tuple in the last assignment statement, w is opened, producing a tuple of four values; 1437 1437 therefore, the right-hand tuple is now the tuple ©[ [ 1, 2, 3, 4 ], 5 ]©. … … 1448 1448 \CFA permits assignment to several variables at once using mass assignment~\cite{CLU}. 1449 1449 Mass assignment has the following form: 1450 \begin{ lstlisting}1450 \begin{cfa} 1451 1451 [ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = §\emph{expr}§; 1452 \end{ lstlisting}1452 \end{cfa} 1453 1453 \index{lvalue} 1454 1454 The left-hand side is a tuple of \emph{lvalues}, which is a list of expressions each yielding an address, i.e., any data object that can appear on the left-hand side of a conventional assignment statement. … … 1457 1457 1458 1458 Mass assignment has parallel semantics, \eg the statement: 1459 \begin{ lstlisting}1459 \begin{cfa} 1460 1460 [ x, y, z ] = 1.5; 1461 \end{ lstlisting}1461 \end{cfa} 1462 1462 is equivalent to: 1463 \begin{ lstlisting}1463 \begin{cfa} 1464 1464 x = 1.5; y = 1.5; z = 1.5; 1465 \end{ lstlisting}1465 \end{cfa} 1466 1466 This semantics is not the same as the following in C: 1467 \begin{ lstlisting}1467 \begin{cfa} 1468 1468 x = y = z = 1.5; 1469 \end{ lstlisting}1469 \end{cfa} 1470 1470 as conversions between intermediate assignments may lose information. 1471 1471 A more complex example is: 1472 \begin{ lstlisting}1472 \begin{cfa} 1473 1473 [ i, y[i], z ] = a + b; 1474 \end{ lstlisting}1474 \end{cfa} 1475 1475 which is equivalent to: 1476 \begin{ lstlisting}1476 \begin{cfa} 1477 1477 t = a + b; 1478 1478 a1 = &i; a2 = &y[i]; a3 = &z; 1479 1479 *a1 = t; *a2 = t; *a3 = t; 1480 \end{ lstlisting}1480 \end{cfa} 1481 1481 The temporary ©t© is necessary to store the value of the expression to eliminate conversion issues. 1482 1482 The temporaries for the addresses are needed so that locations on the left-hand side do not change as the values are assigned. … … 1488 1488 \CFA also supports the assignment of several values at once, known as multiple assignment~\cite{CLU,Galletly96}. 1489 1489 Multiple assignment has the following form: 1490 \begin{ lstlisting}1490 \begin{cfa} 1491 1491 [ §\emph{lvalue}§, ... , §\emph{lvalue}§ ] = [ §\emph{expr}§, ... , §\emph{expr}§ ]; 1492 \end{ lstlisting}1492 \end{cfa} 1493 1493 \index{lvalue} 1494 1494 The left-hand side is a tuple of \emph{lvalues}, and the right-hand side is a tuple of \emph{expr}s. 1495 1495 Each \emph{expr} appearing on the righthand side of a multiple assignment statement is assigned to the corresponding \emph{lvalues} on the left-hand side of the statement using parallel semantics for each assignment. 1496 1496 An example of multiple assignment is: 1497 \begin{ lstlisting}1497 \begin{cfa} 1498 1498 [ x, y, z ] = [ 1, 2, 3 ]; 1499 \end{ lstlisting}1499 \end{cfa} 1500 1500 Here, the values ©1©, ©2© and ©3© are assigned, respectively, to the variables ©x©, ©y© and ©z©. 1501 1501 A more complex example is: 1502 \begin{ lstlisting}1502 \begin{cfa} 1503 1503 [ i, y[ i ], z ] = [ 1, i, a + b ]; 1504 \end{ lstlisting}1504 \end{cfa} 1505 1505 Here, the values ©1©, ©i© and ©a + b© are assigned to the variables ©i©, ©y[i]© and ©z©, respectively. 1506 1506 Note, the parallel semantics of 1507 1507 multiple assignment ensures: 1508 \begin{ lstlisting}1508 \begin{cfa} 1509 1509 [ x, y ] = [ y, x ]; 1510 \end{ lstlisting}1510 \end{cfa} 1511 1511 correctly interchanges (swaps) the values stored in ©x© and ©y©. 1512 1512 The following cases are errors: 1513 \begin{ lstlisting}1513 \begin{cfa} 1514 1514 [ a, b, c ] = [ 1, 2, 3, 4 ]; 1515 1515 [ a, b, c ] = [ 1, 2 ]; 1516 \end{ lstlisting}1516 \end{cfa} 1517 1517 because the number of entities in the left-hand tuple is unequal with the right-hand tuple. 1518 1518 1519 1519 As for all tuple contexts in C, side effects should not be used because C does not define an ordering for the evaluation of the elements of a tuple; 1520 1520 both these examples produce indeterminate results: 1521 \begin{ lstlisting}1521 \begin{cfa} 1522 1522 f( x++, x++ ); §\C{// C routine call with side effects in arguments}§ 1523 1523 [ v1, v2 ] = [ x++, x++ ]; §\C{// side effects in righthand side of multiple assignment}§ 1524 \end{ lstlisting}1524 \end{cfa} 1525 1525 1526 1526 … … 1529 1529 As in C, \CFA mass and multiple assignments can be cascaded, producing cascade assignment. 1530 1530 Cascade assignment has the following form: 1531 \begin{ lstlisting}1531 \begin{cfa} 1532 1532 §\emph{tuple}§ = §\emph{tuple}§ = ... = §\emph{tuple}§; 1533 \end{ lstlisting}1533 \end{cfa} 1534 1534 and it has the same parallel semantics as for mass and multiple assignment. 1535 1535 Some examples of cascade assignment are: 1536 \begin{ lstlisting}1536 \begin{cfa} 1537 1537 x1 = y1 = x2 = y2 = 0; 1538 1538 [ x1, y1 ] = [ x2, y2 ] = [ x3, y3 ]; 1539 1539 [ x1, y1 ] = [ x2, y2 ] = 0; 1540 1540 [ x1, y1 ] = z = 0; 1541 \end{ lstlisting}1541 \end{cfa} 1542 1542 As in C, the rightmost assignment is performed first, i.e., assignment parses right to left. 1543 1543 … … 1546 1546 1547 1547 C requires each field of a structure to have a name, except for a bit field associated with a basic type, \eg: 1548 \begin{ lstlisting}1548 \begin{cfa} 1549 1549 struct { 1550 1550 int f1; §\C{// named field}§ … … 1555 1555 int (*)(int); §\C{// disallowed, unnamed field}§ 1556 1556 }; 1557 \end{ lstlisting}1557 \end{cfa} 1558 1558 This requirement is relaxed by making the field name optional for all field declarations; therefore, all the field declarations in the example are allowed. 1559 1559 As for unnamed bit fields, an unnamed field is used for padding a structure to a particular size. 1560 1560 A list of unnamed fields is also supported, \eg: 1561 \begin{ lstlisting}1561 \begin{cfa} 1562 1562 struct { 1563 1563 int , , ; §\C{// 3 unnamed fields}§ 1564 1564 } 1565 \end{ lstlisting}1565 \end{cfa} 1566 1566 1567 1567 … … 1570 1570 Tuples may be used to select multiple fields of a record by field name. 1571 1571 Its general form is: 1572 \begin{ lstlisting}1572 \begin{cfa} 1573 1573 §\emph{expr}§ . [ §\emph{fieldlist}§ ] 1574 1574 §\emph{expr}§ -> [ §\emph{fieldlist}§ ] 1575 \end{ lstlisting}1575 \end{cfa} 1576 1576 \emph{expr} is any expression yielding a value of type record, \eg ©struct©, ©union©. 1577 1577 Each element of \emph{ fieldlist} is an element of the record specified by \emph{expr}. 1578 1578 A record-field tuple may be used anywhere a tuple can be used. An example of the use of a record-field tuple is 1579 1579 the following: 1580 \begin{ lstlisting}1580 \begin{cfa} 1581 1581 struct s { 1582 1582 int f1, f2; … … 1586 1586 v.[ f3, f1, f2 ] = ['x', 11, 17 ]; §\C{// equivalent to v.f3 = 'x', v.f1 = 11, v.f2 = 17}§ 1587 1587 f( v.[ f3, f1, f2 ] ); §\C{// equivalent to f( v.f3, v.f1, v.f2 )}§ 1588 \end{ lstlisting}1588 \end{cfa} 1589 1589 Note, the fields appearing in a record-field tuple may be specified in any order; 1590 1590 also, it is unnecessary to specify all the fields of a struct in a multiple record-field tuple. 1591 1591 1592 1592 If a field of a ©struct© is itself another ©struct©, multiple fields of this subrecord can be specified using a nested record-field tuple, as in the following example: 1593 \begin{ lstlisting}1593 \begin{cfa} 1594 1594 struct inner { 1595 1595 int f2, f3; … … 1602 1602 1603 1603 o.[ f1, i.[ f2, f3 ], f4 ] = [ 11, 12, 13, 3.14159 ]; 1604 \end{ lstlisting}1604 \end{cfa} 1605 1605 1606 1606 … … 1617 1617 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1618 1618 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 1619 \begin{ lstlisting}1619 \begin{cfa} 1620 1620 ®L1:® do { 1621 1621 ®L2:® while ( ... ) { … … 1627 1627 } // while 1628 1628 } while ( ... ); 1629 \end{ lstlisting}1629 \end{cfa} 1630 1630 & 1631 \begin{ lstlisting}1631 \begin{cfa} 1632 1632 do { 1633 1633 while ( ... ) { … … 1639 1639 L2: ; } 1640 1640 L1: ; } while ( ... ); 1641 \end{ lstlisting}1641 \end{cfa} 1642 1642 \end{tabular} 1643 1643 \end{quote2} … … 1648 1648 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1649 1649 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{C}} \\ 1650 \begin{ lstlisting}1650 \begin{cfa} 1651 1651 ®L1:® { 1652 1652 ... §declarations§ ... … … 1665 1665 } // switch 1666 1666 } // compound 1667 \end{ lstlisting}1667 \end{cfa} 1668 1668 & 1669 \begin{ lstlisting}1669 \begin{cfa} 1670 1670 { 1671 1671 ... §declarations§ ... … … 1684 1684 } L2: ; 1685 1685 } L1: ; 1686 \end{ lstlisting}1686 \end{cfa} 1687 1687 \end{tabular} 1688 1688 \end{quote2} … … 1714 1714 \emph{falls through} to the next ©case© clause in the ©switch© statement; 1715 1715 to exit a ©switch© statement from a ©case© clause requires explicitly terminating the clause with a transfer statement, most commonly ©break©: 1716 \begin{ lstlisting}1716 \begin{cfa} 1717 1717 switch ( i ) { 1718 1718 case 1: … … 1723 1723 break; // exit switch statement 1724 1724 } 1725 \end{ lstlisting}1725 \end{cfa} 1726 1726 The ability to fall-through to the next clause \emph{is} a useful form of control flow, specifically when a sequence of case actions compound: 1727 1727 \begin{quote2} 1728 1728 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 1729 \begin{ lstlisting}1729 \begin{cfa} 1730 1730 switch ( argc ) { 1731 1731 case 3: … … 1738 1738 // usage message 1739 1739 } 1740 \end{ lstlisting}1740 \end{cfa} 1741 1741 & 1742 \begin{ lstlisting}1742 \begin{cfa} 1743 1743 1744 1744 if ( argc == 3 ) { … … 1751 1751 // usage message 1752 1752 } 1753 \end{ lstlisting}1753 \end{cfa} 1754 1754 \end{tabular} 1755 1755 \end{quote2} … … 1757 1757 This control flow is difficult to simulate with if statements or a ©switch© statement without fall-through as code must be duplicated or placed in a separate routine. 1758 1758 C also uses fall-through to handle multiple case-values resulting in the same action: 1759 \begin{ lstlisting}1759 \begin{cfa} 1760 1760 switch ( i ) { 1761 1761 case 1: case 3: case 5: // odd values … … 1766 1766 break; 1767 1767 } 1768 \end{ lstlisting}1768 \end{cfa} 1769 1769 However, this situation is handled in other languages without fall-through by allowing a list of case values. 1770 1770 While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive to many programmers and is different from virtually all other programming languages with a ©switch© statement. … … 1773 1773 \item 1774 1774 It is possible to place ©case© clauses on statements nested \emph{within} the body of the ©switch© statement: 1775 \begin{ lstlisting}1775 \begin{cfa} 1776 1776 switch ( i ) { 1777 1777 case 0: … … 1788 1788 } // while 1789 1789 } // switch 1790 \end{ lstlisting}1790 \end{cfa} 1791 1791 The problem with this usage is branching into control structures, which is known to cause both comprehension and technical difficulties. 1792 1792 The comprehension problem occurs from the inability to determine how control reaches a particular point due to the number of branches leading to it. … … 1795 1795 There are virtually no positive arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it. 1796 1796 Nevertheless, C does have an idiom where this capability is used, known as ``\Index*{Duff's device}''~\cite{Duff83}: 1797 \begin{ lstlisting}1797 \begin{cfa} 1798 1798 register int n = (count + 7) / 8; 1799 1799 switch ( count % 8 ) { … … 1808 1808 } while ( --n > 0 ); 1809 1809 } 1810 \end{ lstlisting}1810 \end{cfa} 1811 1811 which unrolls a loop N times (N = 8 above) and uses the ©switch© statement to deal with any iterations not a multiple of N. 1812 1812 While efficient, this sort of special purpose usage is questionable: … … 1824 1824 \item 1825 1825 It is possible to place unreachable code at the start of a ©switch© statement, as in: 1826 \begin{ lstlisting}1826 \begin{cfa} 1827 1827 switch ( x ) { 1828 1828 ®int y = 1;® §\C{// unreachable initialization}§ … … 1835 1835 ®x = z;® §\C{// without fall through, z is uninitialized}§ 1836 1836 } 1837 \end{ lstlisting}1837 \end{cfa} 1838 1838 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. 1839 1839 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. … … 1858 1858 Eliminating default fall-through has the greatest potential for affecting existing code. 1859 1859 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: 1860 \begin{lstlisting}1860 \begin{cfa} 1861 1861 case 1: case 2: case 3: ... 1862 \end{ lstlisting}1862 \end{cfa} 1863 1863 still works. 1864 1864 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. 1865 1865 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.: 1866 \begin{ lstlisting}1866 \begin{cfa} 1867 1867 ®choose® ( i ) { 1868 1868 case 1: case 2: case 3: … … 1878 1878 j = 3; 1879 1879 } 1880 \end{ lstlisting}1880 \end{cfa} 1881 1881 Like the ©switch© statement, the ©choose© statement retains the fall-through semantics for a list of ©case© clauses; 1882 1882 the implicit ©break© is applied only at the end of the \emph{statements} following a ©case© clause. … … 1893 1893 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. 1894 1894 Further declarations at the same nesting level as the statement body are disallowed to ensure every transfer into the body is sound. 1895 \begin{ lstlisting}1895 \begin{cfa} 1896 1896 switch ( x ) { 1897 1897 ®int i = 0;® §\C{// allowed only at start}§ … … 1906 1906 ... 1907 1907 } 1908 \end{ lstlisting}1908 \end{cfa} 1909 1909 \end{enumerate} 1910 1910 … … 1919 1919 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} 1920 1920 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{C}} \\ 1921 \begin{ lstlisting}1921 \begin{cfa} 1922 1922 switch ( i ) { 1923 1923 case ®1, 3, 5®: … … 1926 1926 ... 1927 1927 } 1928 \end{ lstlisting}1928 \end{cfa} 1929 1929 & 1930 \begin{ lstlisting}1930 \begin{cfa} 1931 1931 switch ( i ) { 1932 1932 case 1: case 3 : case 5: … … 1935 1935 ... 1936 1936 } 1937 \end{ lstlisting}1937 \end{cfa} 1938 1938 & 1939 \begin{ lstlisting}1939 \begin{cfa} 1940 1940 1941 1941 // odd values … … 1944 1944 1945 1945 1946 \end{ lstlisting}1946 \end{cfa} 1947 1947 \end{tabular} 1948 1948 \end{quote2} … … 1952 1952 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{}} 1953 1953 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{GNU C}} \\ 1954 \begin{ lstlisting}1954 \begin{cfa} 1955 1955 switch ( i ) { 1956 1956 case ®1~5:® … … 1959 1959 ... 1960 1960 } 1961 \end{ lstlisting}1961 \end{cfa} 1962 1962 & 1963 \begin{ lstlisting}1963 \begin{cfa} 1964 1964 switch ( i ) 1965 1965 case ®1 ... 5®: … … 1968 1968 ... 1969 1969 } 1970 \end{ lstlisting}1970 \end{cfa} 1971 1971 & 1972 \begin{ lstlisting}1972 \begin{cfa} 1973 1973 1974 1974 // 1, 2, 3, 4, 5 … … 1977 1977 1978 1978 1979 \end{ lstlisting}1979 \end{cfa} 1980 1980 \end{tabular} 1981 1981 \end{quote2} 1982 1982 Lists of subranges are also allowed. 1983 \begin{ lstlisting}1983 \begin{cfa} 1984 1984 case ®1~5, 12~21, 35~42®: 1985 \end{ lstlisting}1985 \end{cfa} 1986 1986 1987 1987 … … 1989 1989 1990 1990 Exception handling provides two mechanism: change of control flow from a raise to a handler, and communication from the raise to the handler. 1991 \begin{ lstlisting}1991 \begin{cfa} 1992 1992 exception void h( int i ); 1993 1993 exception int h( int i, double d ); … … 2006 2006 } finally { 2007 2007 } 2008 \end{ lstlisting}2008 \end{cfa} 2009 2009 So the type raised would be the mangled name of the exception prototype and that name would be matched at the handler clauses by comparing the strings. 2010 2010 The arguments for the call would have to be packed in a message and unpacked at handler clause and then a call made to the handler. … … 2017 2017 \CFA allows users to define new types using the keyword type. 2018 2018 2019 \begin{ lstlisting}2019 \begin{cfa} 2020 2020 // SensorValue is a distinct type and represented as an int 2021 2021 type SensorValue = int; 2022 \end{ lstlisting}2022 \end{cfa} 2023 2023 2024 2024 A type definition is different from a typedef in C because a typedef just creates an alias for a type, while Do.s type definition creates a distinct type. … … 2026 2026 For example: 2027 2027 2028 \begin{ lstlisting}2028 \begin{cfa} 2029 2029 type SensorValue = int; 2030 2030 void printValue(int v) {...} … … 2039 2039 2040 2040 process(s); // implicit conversion to int 2041 \end{ lstlisting}2041 \end{cfa} 2042 2042 2043 2043 If SensorValue was defined with a typedef, then these two print functions would not have unique signatures. … … 2047 2047 Users may override this and define a function that must be called to convert from one type to another. 2048 2048 2049 \begin{ lstlisting}2049 \begin{cfa} 2050 2050 type SensorValue = int; 2051 2051 // ()? is the overloaded conversion operator identifier … … 2058 2058 SensorValue s = ...; 2059 2059 process(s); // implicit call to conversion operator 2060 \end{ lstlisting}2060 \end{cfa} 2061 2061 2062 2062 In many cases, it is not desired for the compiler to do this implicit conversion. … … 2064 2064 Any places where the conversion is needed but not explicit (with a cast), will result in a compile-time error. 2065 2065 2066 \begin{ lstlisting}2066 \begin{cfa} 2067 2067 type SensorValue = int; 2068 2068 … … 2077 2077 process(s); // implicit cast to int: compile-time error 2078 2078 process((int) s); // explicit cast to int: calls conversion func 2079 \end{ lstlisting}2079 \end{cfa} 2080 2080 2081 2081 The conversion may not require any code, but still need to be explicit; in that case, the syntax can be simplified to: 2082 \begin{ lstlisting}2082 \begin{cfa} 2083 2083 type SensorValue = int; 2084 2084 explicit SensorValue ()?(int); … … 2088 2088 process(s); // compile-time error 2089 2089 process((int) s); // type is converted, no function is called 2090 \end{ lstlisting}2090 \end{cfa} 2091 2091 2092 2092 … … 2096 2096 A structure is defined with the same syntax as in C. 2097 2097 When referring to a structure in \CFA, users may omit the struct keyword. 2098 \begin{ lstlisting}2098 \begin{cfa} 2099 2099 struct Point { 2100 2100 double x; … … 2103 2103 2104 2104 Point p = {0.0, 0.0}; 2105 \end{ lstlisting}2105 \end{cfa} 2106 2106 2107 2107 \CFA does not support inheritance among types, but instead uses composition to enable reuse of structure fields. … … 2110 2110 Embedding types is achieved using anonymous members. 2111 2111 For example, using Point from above: 2112 \begin{ lstlisting}2112 \begin{cfa} 2113 2113 void foo(Point p); 2114 2114 … … 2122 2122 cp.color = 0x33aaff; // color is accessed normally 2123 2123 foo(cp); // cp can be used directly as a Point 2124 \end{ lstlisting}2124 \end{cfa} 2125 2125 2126 2126 … … 2132 2132 2133 2133 \begin{figure} 2134 \begin{ lstlisting}2134 \begin{cfa} 2135 2135 struct Widget { 2136 2136 int id; … … 2174 2174 ^bar; // explicit call to destructor 2175 2175 ^?(bar); // explicit call to destructor 2176 \end{ lstlisting}2176 \end{cfa} 2177 2177 \caption{Constructors and Destructors} 2178 2178 \end{figure} … … 2211 2211 If there is no single best valid interpretation, or if the best valid interpretation is ambiguous, then the resulting interpretation is ambiguous. 2212 2212 For details about type inference and overload resolution, please see the \CFA Language Specification. 2213 \begin{ lstlisting}2213 \begin{cfa} 2214 2214 int foo(int a, int b) { 2215 2215 float sum = 0.0; … … 2224 2224 ... 2225 2225 } 2226 \end{ lstlisting}2226 \end{cfa} 2227 2227 2228 2228 … … 2245 2245 For example, to define the constants for a complex type, the programmer would define the following: 2246 2246 2247 \begin{ lstlisting}2247 \begin{cfa} 2248 2248 struct Complex { 2249 2249 double real; … … 2263 2263 ... 2264 2264 } 2265 \end{ lstlisting}2265 \end{cfa} 2266 2266 2267 2267 … … 2271 2271 Allowing overloading of variable names enables programmers to use the same name across multiple types, simplifying naming conventions and is compatible with the other overloading that is allowed. 2272 2272 For example, a developer may want to do the following: 2273 \begin{ lstlisting}2273 \begin{cfa} 2274 2274 int pi = 3; 2275 2275 float pi = 3.14; 2276 2276 char pi = .p.; 2277 \end{ lstlisting}2277 \end{cfa} 2278 2278 2279 2279 … … 2283 2283 2284 2284 The examples below give some basic intuition about how the resolution works. 2285 \begin{ lstlisting}2285 \begin{cfa} 2286 2286 // Choose the one with less conversions 2287 2287 int doSomething(int value) {...} // option 1 … … 2306 2306 2307 2307 f = bar(d, e); // chooses option 5 2308 \end{ lstlisting}2308 \end{cfa} 2309 2309 2310 2310 … … 2376 2376 These operators are called using the normal C syntax. 2377 2377 2378 \begin{ lstlisting}2378 \begin{cfa} 2379 2379 type Complex = struct { // define a Complex type 2380 2380 double real; … … 2406 2406 c = a + b; 2407 2407 print(.sum = . + c); 2408 \end{ lstlisting}2408 \end{cfa} 2409 2409 2410 2410 … … 2415 2415 \begin{tabular}{@{}l@{\hspace{3em}}ll@{}} 2416 2416 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CC}} & \multicolumn{1}{c}{Indexc{gcc}} \\ 2417 \begin{ lstlisting}2417 \begin{cfa} 2418 2418 2419 2419 auto j = 3.0 * 4; 2420 2420 int i; 2421 2421 auto k = i; 2422 \end{ lstlisting}2422 \end{cfa} 2423 2423 & 2424 \begin{ lstlisting}2424 \begin{cfa} 2425 2425 #define expr 3.0 * i 2426 2426 typeof(expr) j = expr; 2427 2427 int i; 2428 2428 typeof(i) k = i; 2429 \end{ lstlisting}2429 \end{cfa} 2430 2430 & 2431 \begin{ lstlisting}2431 \begin{cfa} 2432 2432 2433 2433 // use type of initialization expression 2434 2434 2435 2435 // use type of primary variable 2436 \end{ lstlisting}2436 \end{cfa} 2437 2437 \end{tabular} 2438 2438 \end{quote2} … … 2451 2451 Finally, ©auto© presents the programming problem of tracking down a type when the type is actually needed. 2452 2452 For example, given 2453 \begin{ lstlisting}2453 \begin{cfa} 2454 2454 auto j = ®...® 2455 \end{ lstlisting}2455 \end{cfa} 2456 2456 and the need to write a routine to compute using ©j© 2457 \begin{ lstlisting}2457 \begin{cfa} 2458 2458 void rtn( ®...® parm ); 2459 2459 rtn( j ); 2460 \end{ lstlisting}2460 \end{cfa} 2461 2461 A programmer must work backwards to determine the type of ©j©'s initialization expression, reconstructing the possibly long generic type-name. 2462 2462 In this situation, having the type name or a short alias is very useful. … … 2488 2488 A simple example of using Do.s parametric polymorphism to create a generic swap function would look like this: 2489 2489 2490 \begin{ lstlisting}2490 \begin{cfa} 2491 2491 generic(type T) 2492 2492 void swap(T &a, T &b) { … … 2501 2501 Point p1, p2; 2502 2502 swap(p1, p2); 2503 \end{ lstlisting}2503 \end{cfa} 2504 2504 2505 2505 Here, instead of specifying types for the parameters a and b, the function has a generic type parameter, type T. … … 2511 2511 Some generic functions only work (or make sense) for any type that satisfies a given property. 2512 2512 For example, here is a function to pick the minimum of two values of some type. 2513 \begin{ lstlisting}2513 \begin{cfa} 2514 2514 generic (type T | bool ?<?(T, T) ) 2515 2515 … … 2517 2517 return a < b ? a : b; 2518 2518 } 2519 \end{ lstlisting}2519 \end{cfa} 2520 2520 2521 2521 It only makes sense to call min with values of a type that has an ordering: a way to decide whether one value is less than another. … … 2526 2526 2527 2527 Bounds can also involve multiple types, and multiple requirements, as shown below: 2528 \begin{ lstlisting}2528 \begin{cfa} 2529 2529 generic (type T, type U | { T foo(T, U); U bar(U); }) 2530 2530 … … 2532 2532 return foo(t, bar(u)); 2533 2533 } 2534 \end{ lstlisting}2534 \end{cfa} 2535 2535 2536 2536 … … 2546 2546 This avoids repetition when a bound is used in many functions. 2547 2547 Second, interfaces explicitly document the existence of a commonly used set of functionality, making programs easier to understand. 2548 \begin{ lstlisting}2548 \begin{cfa} 2549 2549 generic (type T) 2550 2550 interface Orderable { … … 2556 2556 return a < b ? a : b; 2557 2557 } 2558 \end{ lstlisting}2558 \end{cfa} 2559 2559 2560 2560 This definition of the interface Orderable makes the generic function min easier to read and understand. … … 2562 2562 Interfaces can also build on top of other interfaces. 2563 2563 For example: 2564 \begin{ lstlisting}2564 \begin{cfa} 2565 2565 generic (type T | Orderable(T) 2566 2566 interface FooBarable { … … 2568 2568 int Bar(T, T); 2569 2569 }; 2570 \end{ lstlisting}2570 \end{cfa} 2571 2571 2572 2572 The FooBarable interface specifies all of the bounds of the Orderable interface, plus the additional bounds specified in its definition. … … 2579 2579 Type synonyms can be defined generically using the typedef keyword together with a generic type annotation. 2580 2580 These can be used to abbreviate complicated type expressions, especially in generic code. 2581 \begin{ lstlisting}2581 \begin{cfa} 2582 2582 // typedef the generic function pointers for later use 2583 2583 … … 2594 2594 if (p(array[i])) f(NULL, array[i]); 2595 2595 } 2596 \end{ lstlisting}2596 \end{cfa} 2597 2597 2598 2598 … … 2608 2608 The syntax for defining a generic type looks very similar to that of a generic function. 2609 2609 Generic types support bounds and interfaces, using the same syntax as generic functions. 2610 \begin{ lstlisting}2610 \begin{cfa} 2611 2611 generic (type T) 2612 2612 struct LinkedListElem { … … 2632 2632 return false; 2633 2633 } 2634 \end{ lstlisting}2634 \end{cfa} 2635 2635 2636 2636 … … 2655 2655 An exception is thrown using a throw statement, which accepts one argument. 2656 2656 2657 \begin{ lstlisting}2657 \begin{cfa} 2658 2658 ... 2659 2659 … … 2661 2661 2662 2662 ... 2663 \end{ lstlisting}2663 \end{cfa} 2664 2664 2665 2665 An exception can be caught using a catch statement, which specifies the type of the exception it can catch. … … 2667 2667 A guarded block is specified using the try keyword, followed by a block of code inside of curly braces. 2668 2668 2669 \begin{ lstlisting}2669 \begin{cfa} 2670 2670 ... 2671 2671 … … 2676 2676 printf(.caught an exception: %d\n., e); 2677 2677 } 2678 \end{ lstlisting}2678 \end{cfa} 2679 2679 2680 2680 … … 2691 2691 Instead, it infers the type based on the return value, and then allocates space for the inferred type. 2692 2692 2693 \begin{ lstlisting}2693 \begin{cfa} 2694 2694 float *f = malloc(); // allocates the size of a float 2695 2695 … … 2699 2699 2700 2700 struct S *s = malloc(); // allocates the size of a struct S 2701 \end{ lstlisting}2701 \end{cfa} 2702 2702 2703 2703 In addition to the improved malloc, \CFA also provides a technique for combining allocation and initialization into one step, using the new function. 2704 2704 For all constructors defined for a given type (see Operator Overloading), a corresponding call to new can be used to allocate and construct that type. 2705 2705 2706 \begin{ lstlisting}2706 \begin{cfa} 2707 2707 type Complex = struct { 2708 2708 float real; … … 2737 2737 } 2738 2738 2739 \end{ lstlisting}2739 \end{cfa} 2740 2740 2741 2741 … … 2764 2764 The number 0 and 1 are treated specially in \CFA, and can be redefined as variables. 2765 2765 One syntactic anomaly is when a field in an structure is names 0 or 1: 2766 \begin{ lstlisting}2766 \begin{cfa} 2767 2767 struct S { 2768 2768 int 0, 1; 2769 2769 } s; 2770 \end{ lstlisting}2770 \end{cfa} 2771 2771 The problem occurs in accessing these fields using the selection operation ``©.©'': 2772 \begin{ lstlisting}2772 \begin{cfa} 2773 2773 s.0 = 0; // ambiguity with floating constant .0 2774 2774 s.1 = 1; // ambiguity with floating constant .1 2775 \end{ lstlisting}2775 \end{cfa} 2776 2776 To make this work, a space is required after the field selection: 2777 \begin{ lstlisting}2777 \begin{cfa} 2778 2778 ®s.§\textvisiblespace§0® = 0; 2779 2779 ®s.§\textvisiblespace§1® = 1; 2780 \end{ lstlisting}2780 \end{cfa} 2781 2781 While this syntax is awkward, it is unlikely many programmers will name fields of a structure 0 or 1. 2782 2782 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. … … 2786 2786 Even with this special hack, there are 5 general cases that cannot be handled. 2787 2787 The first case is for the function-call identifier ©?()©: 2788 \begin{ lstlisting}2788 \begin{cfa} 2789 2789 int *§\textvisiblespace§?()(); // declaration: space required after '*' 2790 2790 *§\textvisiblespace§?()(); // expression: space required after '*' 2791 \end{ lstlisting}2791 \end{cfa} 2792 2792 Without the space, the string ©*?()© is ambiguous without N character look ahead; 2793 2793 it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument/parameter list. 2794 2794 2795 2795 The 4 remaining cases occur in expressions: 2796 \begin{ lstlisting}2796 \begin{cfa} 2797 2797 i++§\textvisiblespace§?i:0; // space required before '?' 2798 2798 i--§\textvisiblespace§?i:0; // space required before '?' 2799 2799 i§\textvisiblespace§?++i:0; // space required after '?' 2800 2800 i§\textvisiblespace§?--i:0; // space required after '?' 2801 \end{ lstlisting}2801 \end{cfa} 2802 2802 In the first two cases, the string ©i++?© is ambiguous, where this string can be lexed as ©i© / ©++?© or ©i++© / ©?©; 2803 2803 it requires scanning ahead to determine if there is a ©'('©, which is the start of an argument list. … … 2835 2835 Users of a monitor interact with it just like any structure, but the compiler handles code as needed to ensure mutual exclusion. 2836 2836 An example of the definition of a monitor is shown here: 2837 \begin{ lstlisting}2837 \begin{cfa} 2838 2838 type Account = monitor { 2839 2839 const unsigned long number; // account number 2840 2840 float balance; // account balance 2841 2841 }; 2842 \end{ lstlisting}2842 \end{cfa} 2843 2843 2844 2844 Since a monitor structure includes an implicit locking mechanism, it does not make sense to copy a monitor; … … 2850 2850 If multiple mutex parameters are specified, they will be locked in parameter order (\ie first parameter is locked first) and unlocked in the 2851 2851 reverse order. 2852 \begin{ lstlisting}2852 \begin{cfa} 2853 2853 // This function accesses a constant field, it does not require 2854 2854 // mutual exclusion … … 2865 2865 return a.balance; 2866 2866 } 2867 \end{ lstlisting}2867 \end{cfa} 2868 2868 2869 2869 Often, one function using a monitor will call another function using that same monitor. … … 2873 2873 An example of this situation is shown below: 2874 2874 2875 \begin{ lstlisting}2875 \begin{cfa} 2876 2876 // deleting a job from a worker requires mutual exclusion 2877 2877 … … 2887 2887 ... 2888 2888 } 2889 \end{ lstlisting}2889 \end{cfa} 2890 2890 2891 2891 … … 2895 2895 A task provides mutual exclusion like a monitor, and also has its own execution state and a thread of control. 2896 2896 Similar to a monitor, a task is defined like a structure: 2897 \begin{ lstlisting}2897 \begin{cfa} 2898 2898 type Adder = task { 2899 2899 int *row; … … 2901 2901 int &subtotal; 2902 2902 } 2903 \end{ lstlisting}2903 \end{cfa} 2904 2904 2905 2905 A task may define a constructor, which will be called upon allocation and run on the caller.s thread. … … 2909 2909 Below are example functions for the above Adder task, and its usage to sum up a matrix on multiple threads. 2910 2910 (Note that this example is designed to display the syntax and functionality, not the best method to solve this problem) 2911 \begin{ lstlisting}2911 \begin{cfa} 2912 2912 void ?{}(Adder &a, int r[], int s, int &st) { // constructor 2913 2913 a.row = r; … … 2946 2946 printf(.total is %d\n., total); 2947 2947 } 2948 \end{ lstlisting}2948 \end{cfa} 2949 2949 2950 2950 … … 2959 2959 Similarly, when a task tries to push something onto the list, but it is full, it will yield until another task frees some space with the pop function. 2960 2960 2961 \begin{ lstlisting}2961 \begin{cfa} 2962 2962 // type T is used as a generic type for all definitions inside 2963 2963 // the curly brackets … … 2984 2984 } 2985 2985 } 2986 \end{ lstlisting}2986 \end{cfa} 2987 2987 2988 2988 A task can also yield indefinitely by calling yield with no arguments. … … 2991 2991 The code below shows a simple ping-pong example, where two tasks yield back and forth to each other using these methods. 2992 2992 2993 \begin{ lstlisting}2993 \begin{cfa} 2994 2994 type Ping = task { 2995 2995 Pong *partner; … … 3029 3029 Ping{pong}; // initialize and start ping 3030 3030 } 3031 \end{ lstlisting}3031 \end{cfa} 3032 3032 3033 3033 The same functionality can be accomplished by providing functions to be called by the partner task. 3034 \begin{ lstlisting}3034 \begin{cfa} 3035 3035 type Pingpong = task { 3036 3036 String msg; … … 3060 3060 go(ping); 3061 3061 } 3062 \end{ lstlisting}3062 \end{cfa} 3063 3063 3064 3064 … … 3092 3092 Within a module, all of the module's global definitions are visible throughout the module. 3093 3093 For example, the following code compiles, even though ©isOdd© was not declared before being called: 3094 \begin{ lstlisting}3094 \begin{cfa} 3095 3095 bool isEven(unsigned int x) { 3096 3096 if (x == 0) return true; … … 3102 3102 else return !isEven(x - 2); 3103 3103 } 3104 \end{ lstlisting}3104 \end{cfa} 3105 3105 3106 3106 Header files in C are used to expose the declarations from a library, so that they can be used externally. … … 3137 3137 3138 3138 The following code is a simple module declaration example. 3139 \begin{ lstlisting}3139 \begin{cfa} 3140 3140 module M; 3141 3141 … … 3150 3150 3151 3151 double bCounter; 3152 \end{ lstlisting}3152 \end{cfa} 3153 3153 3154 3154 export module moduleName; can be use to re-export all the visible (exported) names in moduleName from the current module. … … 3171 3171 The following code snippets show the two situations. 3172 3172 3173 \begin{ lstlisting}3173 \begin{cfa} 3174 3174 module util/counter; 3175 3175 export int f(int i) { return i+1; } … … 3185 3185 return ct.f(200); // f() from the package counter 3186 3186 } 3187 \end{ lstlisting}3187 \end{cfa} 3188 3188 3189 3189 3190 3190 Additionally, using the .as. syntax, a user can force the compiler to add the imported names into the current namespace using .as ..With these module rules, the following module definitions and imports can be achieved without any problem. 3191 3191 3192 \begin{ lstlisting}3192 \begin{cfa} 3193 3193 module M1; 3194 3194 export int f(int i) { return i+1;} // visible outside … … 3208 3208 return f(3) + g(4); //f() from M1 and g() from M2; 3209 3209 } 3210 \end{ lstlisting}3210 \end{cfa} 3211 3211 3212 3212 … … 3225 3225 If an aggregated module is imported, all the included modules in the aggregation are imported. 3226 3226 3227 \begin{ lstlisting}3227 \begin{cfa} 3228 3228 module std/sequence; 3229 3229 … … 3237 3237 module std/stack; 3238 3238 }; 3239 \end{ lstlisting}3239 \end{cfa} 3240 3240 3241 3241 After importing the aggregated module, each individual name is still contained in the original name space. … … 3341 3341 3342 3342 Here is an example of a package, util. 3343 \begin{ lstlisting}3343 \begin{cfa} 3344 3344 + util 3345 3345 Do.prj #package description file … … 3357 3357 sequence.do #Case 4, module std/sequence; 3358 3358 test.do #Case 5 3359 \end{ lstlisting}3359 \end{cfa} 3360 3360 3361 3361 \begin{itemize} … … 3435 3435 Here is a simple example of the directory structure of a package, core. 3436 3436 It contains a module std and several sub-modules under std. 3437 \begin{ lstlisting}3437 \begin{cfa} 3438 3438 + core 3439 3439 Do.prj … … 3445 3445 vector.do #module std/container/vector; 3446 3446 list.do #module std/container/list; 3447 \end{ lstlisting}3447 \end{cfa} 3448 3448 3449 3449 … … 3534 3534 3535 3535 Here is an example of a package, util. 3536 \begin{ lstlisting}3536 \begin{cfa} 3537 3537 + util 3538 3538 Do.prj #package description file … … 3550 3550 sequence.do #Case 4, module std/sequence; 3551 3551 test.do #Case 5 3552 \end{ lstlisting}3552 \end{cfa} 3553 3553 3554 3554 … … 3641 3641 \subsubsection{Package and Module Locating Example} 3642 3642 3643 \begin{ lstlisting}3643 \begin{cfa} 3644 3644 # A project's source code tree 3645 3645 … … 3676 3676 3677 3677 ---------------------------------------- 3678 \end{ lstlisting}3679 3680 3681 \begin{ lstlisting}3678 \end{cfa} 3679 3680 3681 \begin{cfa} 3682 3682 # pkg directory's source code tree 3683 3683 … … 3700 3700 security.do #module security; 3701 3701 ------------------------------------------ 3702 \end{ lstlisting}3702 \end{cfa} 3703 3703 3704 3704 … … 3744 3744 \multicolumn{1}{c|}{\textbf{\CFA}} & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}} \\ 3745 3745 \hline 3746 \begin{ lstlisting}3746 \begin{cfa} 3747 3747 struct Line { 3748 3748 float lnth; … … 3771 3771 Line line1; 3772 3772 Line line2 = { 3.4 }; 3773 \end{ lstlisting}3773 \end{cfa} 3774 3774 & 3775 3775 \begin{lstlisting}[language=C++] … … 3831 3831 \end{lstlisting} 3832 3832 & 3833 \begin{ lstlisting}3833 \begin{cfa} 3834 3834 struct Line { 3835 3835 length: f32 … … 3858 3858 let line1:Line = Default::default(); 3859 3859 Line line2( 3.4 ); 3860 \end{ lstlisting}3860 \end{cfa} 3861 3861 \end{tabular} 3862 3862 \end{flushleft} … … 3869 3869 \multicolumn{1}{c|}{\textbf{\CFA}} & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}} \\ 3870 3870 \hline 3871 \begin{ lstlisting}3871 \begin{cfa} 3872 3872 struct Cpx { 3873 3873 double re, im; … … 3879 3879 Cpx a, b, c; 3880 3880 c = a + b; 3881 \end{ lstlisting}3881 \end{cfa} 3882 3882 & 3883 \begin{ lstlisting}3883 \begin{cfa} 3884 3884 struct Cpx { 3885 3885 double re, im; … … 3891 3891 Cpx a, b, c; 3892 3892 c = a + b; 3893 \end{ lstlisting}3893 \end{cfa} 3894 3894 & 3895 \begin{ lstlisting}3895 \begin{cfa} 3896 3896 // no operator overloading 3897 3897 … … 3902 3902 3903 3903 3904 \end{ lstlisting}3904 \end{cfa} 3905 3905 & 3906 \begin{ lstlisting}3906 \begin{cfa} 3907 3907 struct Cpx { 3908 3908 re: f32, … … 3921 3921 let (a, b, mut c) = ...; 3922 3922 c = a + b 3923 \end{ lstlisting}3923 \end{cfa} 3924 3924 \end{tabular} 3925 3925 \end{flushleft} … … 3932 3932 \multicolumn{1}{c|}{\textbf{\CFA/\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}} \\ 3933 3933 \hline 3934 \begin{ lstlisting}[boxpos=t]3934 \begin{cfa}[boxpos=t] 3935 3935 extern "C" { 3936 3936 #include <sys/types.h> … … 3943 3943 return s.st_size; 3944 3944 } 3945 \end{ lstlisting}3945 \end{cfa} 3946 3946 & 3947 \begin{ lstlisting}[boxpos=t]3947 \begin{cfa}[boxpos=t] 3948 3948 /* 3949 3949 #cgo … … 3962 3962 return buf._st_size 3963 3963 } 3964 \end{ lstlisting}3964 \end{cfa} 3965 3965 & 3966 \begin{ lstlisting}[boxpos=t]3966 \begin{cfa}[boxpos=t] 3967 3967 use libc::{c_int, size_t}; 3968 3968 // translated from sys/stat.h … … 3986 3986 } 3987 3987 } 3988 \end{ lstlisting}3988 \end{cfa} 3989 3989 \end{tabular} 3990 3990 \end{flushleft} … … 3997 3997 \multicolumn{1}{c|}{\textbf{\CFA}} & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}} \\ 3998 3998 \hline 3999 \begin{ lstlisting}3999 \begin{cfa} 4000 4000 generic(type T, type N | 4001 4001 { int ?<?(N, N); }) … … 4018 4018 return maximize(length, n, p); 4019 4019 } 4020 \end{ lstlisting}4020 \end{cfa} 4021 4021 & 4022 \begin{ lstlisting}4022 \begin{cfa} 4023 4023 template<typename T, typename F> 4024 4024 T *maximize(const F &f, … … 4043 4043 }, n, p); 4044 4044 } 4045 \end{ lstlisting}4045 \end{cfa} 4046 4046 & 4047 \begin{ lstlisting}4047 \begin{cfa} 4048 4048 // Go does not support generics! 4049 4049 func maximize( … … 4073 4073 a).(string) 4074 4074 } 4075 \end{ lstlisting}4075 \end{cfa} 4076 4076 & 4077 \begin{ lstlisting}4077 \begin{cfa} 4078 4078 use std::cmp::Ordering; 4079 4079 … … 4101 4101 maximize(|x: &String| x.len(), a) 4102 4102 } 4103 \end{ lstlisting}4103 \end{cfa} 4104 4104 \end{tabular} 4105 4105 \end{flushleft} … … 4109 4109 \subsubsection{Modules / Packages} 4110 4110 4111 \begin{ lstlisting}4111 \begin{cfa} 4112 4112 \CFA 4113 4113 \CC … … 4185 4185 println!(.{}., M::inc(100)); 4186 4186 } 4187 \end{ lstlisting}4187 \end{cfa} 4188 4188 \end{comment} 4189 4189 … … 4195 4195 \multicolumn{1}{c|}{\textbf{\CFA}} & \multicolumn{1}{c|}{\textbf{\CC}} & \multicolumn{1}{c|}{\textbf{Go}} & \multicolumn{1}{c}{\textbf{Rust}} \\ 4196 4196 \hline 4197 \begin{ lstlisting}4197 \begin{cfa} 4198 4198 task Nonzero { 4199 4199 int *data; … … 4236 4236 return res; 4237 4237 } 4238 \end{ lstlisting}4238 \end{cfa} 4239 4239 & 4240 \begin{ lstlisting}4240 \begin{cfa} 4241 4241 #include <thread> 4242 4242 #include <mutex> … … 4279 4279 return res; 4280 4280 } 4281 \end{ lstlisting}4281 \end{cfa} 4282 4282 & 4283 \begin{ lstlisting}4283 \begin{cfa} 4284 4284 package main 4285 4285 … … 4304 4304 fmt.Println(res) 4305 4305 } 4306 \end{ lstlisting}4306 \end{cfa} 4307 4307 & 4308 \begin{ lstlisting}4308 \begin{cfa} 4309 4309 use std::thread; 4310 4310 use std::sync:mpsc::channel; … … 4339 4339 println!(.{}., res); 4340 4340 } 4341 \end{ lstlisting}4341 \end{cfa} 4342 4342 \end{tabular} 4343 4343 \end{flushleft} … … 4436 4436 \begin{description} 4437 4437 \item[Change:] type of character literal ©int© to ©char© to allow more intuitive overloading: 4438 \begin{ lstlisting}4438 \begin{cfa} 4439 4439 int rtn( int i ); 4440 4440 int rtn( char c ); 4441 4441 rtn( 'x' ); §\C{// programmer expects 2nd rtn to be called}§ 4442 \end{ lstlisting}4442 \end{cfa} 4443 4443 \item[Rationale:] it is more intuitive for the call to ©rtn© to match the second version of definition of ©rtn© rather than the first. 4444 4444 In particular, output of ©char© variable now print a character rather than the decimal ASCII value of the character. 4445 \begin{ lstlisting}4445 \begin{cfa} 4446 4446 sout | 'x' | " " | (int)'x' | endl; 4447 4447 x 120 4448 \end{ lstlisting}4448 \end{cfa} 4449 4449 Having to cast ©'x'© to ©char© is non-intuitive. 4450 4450 \item[Effect on original feature:] change to semantics of well-defined feature that depend on: 4451 \begin{ lstlisting}4451 \begin{cfa} 4452 4452 sizeof( 'x' ) == sizeof( int ) 4453 \end{ lstlisting}4453 \end{cfa} 4454 4454 no long work the same in \CFA programs. 4455 4455 \item[Difficulty of converting:] simple … … 4460 4460 \begin{description} 4461 4461 \item[Change:] make string literals ©const©: 4462 \begin{ lstlisting}4462 \begin{cfa} 4463 4463 char * p = "abc"; §\C{// valid in C, deprecated in \CFA}§ 4464 4464 char * q = expr ? "abc" : "de"; §\C{// valid in C, invalid in \CFA}§ 4465 \end{ lstlisting}4465 \end{cfa} 4466 4466 The type of a string literal is changed from ©[] char© to ©const [] char©. 4467 4467 Similarly, the type of a wide string literal is changed from ©[] wchar_t© to ©const [] wchar_t©. 4468 4468 \item[Rationale:] This change is a safety issue: 4469 \begin{ lstlisting}4469 \begin{cfa} 4470 4470 char * p = "abc"; 4471 4471 p[0] = 'w'; §\C{// segment fault or change constant literal}§ 4472 \end{ lstlisting}4472 \end{cfa} 4473 4473 The same problem occurs when passing a string literal to a routine that changes its argument. 4474 4474 \item[Effect on original feature:] change to semantics of well-defined feature. … … 4480 4480 \begin{description} 4481 4481 \item[Change:] remove \newterm{tentative definitions}, which only occurs at file scope: 4482 \begin{ lstlisting}4482 \begin{cfa} 4483 4483 int i; §\C{// forward definition}§ 4484 4484 int *j = ®&i®; §\C{// forward reference, valid in C, invalid in \CFA}§ 4485 4485 int i = 0; §\C{// definition}§ 4486 \end{ lstlisting}4486 \end{cfa} 4487 4487 is valid in C, and invalid in \CFA because duplicate overloaded object definitions at the same scope level are disallowed. 4488 4488 This change makes it impossible to define mutually referential file-local static objects, if initializers are restricted to the syntactic forms of C. For example, 4489 \begin{ lstlisting}4489 \begin{cfa} 4490 4490 struct X { int i; struct X *next; }; 4491 4491 static struct X a; §\C{// forward definition}§ 4492 4492 static struct X b = { 0, ®&a® }; §\C{// forward reference, valid in C, invalid in \CFA}§ 4493 4493 static struct X a = { 1, &b }; §\C{// definition}§ 4494 \end{ lstlisting}4494 \end{cfa} 4495 4495 \item[Rationale:] avoids having different initialization rules for builtin types and userdefined types. 4496 4496 \item[Effect on original feature:] change to semantics of well-defined feature. … … 4502 4502 \begin{description} 4503 4503 \item[Change:] have ©struct© introduce a scope for nested types: 4504 \begin{ lstlisting}4504 \begin{cfa} 4505 4505 enum ®Colour® { R, G, B, Y, C, M }; 4506 4506 struct Person { … … 4516 4516 Personß.ß®Colour® pc = Personß.ßR; §\C{// type/enum defined inside}§ 4517 4517 Personß.ßFace pretty; §\C{// type defined inside}§ 4518 \end{ lstlisting}4518 \end{cfa} 4519 4519 In C, the name of the nested types belongs to the same scope as the name of the outermost enclosing structure, i.e., the nested types are hoisted to the scope of the outer-most type, which is not useful and confusing. 4520 4520 \CFA is C \emph{incompatible} on this issue, and provides semantics similar to \Index*[C++]{\CC}. … … 4531 4531 \item[Rationale:] C++ classes have member functions which require that classes establish scopes. 4532 4532 \item[Difficulty of converting:] Semantic transformation. To make the struct type name visible in the scope of the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing struct is defined. Example: 4533 \begin{ lstlisting}4533 \begin{cfa} 4534 4534 struct Y; §\C{// struct Y and struct X are at the same scope}§ 4535 4535 struct X { 4536 4536 struct Y { /* ... */ } y; 4537 4537 }; 4538 \end{ lstlisting}4538 \end{cfa} 4539 4539 All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the enclosing struct could be exported to the scope of the enclosing struct. 4540 4540 Note: this is a consequence of the difference in scope rules, which is documented in 3.3. … … 4602 4602 \begin{tabular}{@{}l@{\hspace{3em}}l@{}} 4603 4603 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{\CC}} \\ 4604 \begin{ lstlisting}4604 \begin{cfa} 4605 4605 int x = 0, y = 1, z = 2; 4606 4606 ®sout® ®|® x ®|® y ®|® z ®| endl®; 4607 \end{ lstlisting}4607 \end{cfa} 4608 4608 & 4609 \begin{ lstlisting}4609 \begin{cfa} 4610 4610 4611 4611 cout << x << " " << y << " " << z << endl; 4612 \end{ lstlisting}4612 \end{cfa} 4613 4613 \end{tabular} 4614 4614 \end{quote2} … … 4621 4621 \textbf{\CFA:} 4622 4622 & 4623 \begin{ lstlisting}4623 \begin{cfa} 4624 4624 sout | x * 3 | y + 1 | z << 2 | x == y | (x | y) | (x || y) | (x > z ? 1 : 2) | endl; 4625 \end{ lstlisting}4625 \end{cfa} 4626 4626 \\ 4627 4627 \textbf{\CC:} 4628 4628 & 4629 \begin{ lstlisting}4629 \begin{cfa} 4630 4630 cout << x * 3 << y + 1 << (z << 2) << (x == y) << (x | y) << (x || y) << (x > z ? 1 : 2) << endl; 4631 \end{ lstlisting}4631 \end{cfa} 4632 4632 \end{tabular} 4633 4633 \end{quote2} … … 4639 4639 \item 4640 4640 A separator does not appear at the start or end of a line. 4641 \begin{ lstlisting}[belowskip=0pt]4641 \begin{cfa}[belowskip=0pt] 4642 4642 sout | 1 | 2 | 3 | endl; 4643 \end{ lstlisting}4644 \begin{ lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]4643 \end{cfa} 4644 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 4645 4645 1 2 3 4646 \end{ lstlisting}4646 \end{cfa} 4647 4647 \item 4648 4648 A separator does not appear before or after a character literal or variable. 4649 \begin{ lstlisting}4649 \begin{cfa} 4650 4650 sout | '1' | '2' | '3' | endl; 4651 4651 123 4652 \end{ lstlisting}4652 \end{cfa} 4653 4653 \item 4654 4654 A separator does not appear before or after a null (empty) C string 4655 \begin{ lstlisting}4655 \begin{cfa} 4656 4656 sout | 1 | "" | 2 | "" | 3 | endl; 4657 4657 123 4658 \end{ lstlisting}4658 \end{cfa} 4659 4659 which is a local mechanism to disable insertion of the separator character. 4660 4660 \item 4661 4661 A separator does not appear before a C string starting with the (extended) \Index{ASCII}\index{ASCII!extended} characters: \lstinline[mathescape=off]@([{=$£¥¡¿«@ 4662 4662 %$ 4663 \begin{ lstlisting}[mathescape=off]4663 \begin{cfa}[mathescape=off] 4664 4664 sout | "x (" | 1 | "x [" | 2 | "x {" | 3 | "x =" | 4 | "x $" | 5 | "x £" | 6 | "x ¥" | 7 4665 4665 | "x ¡" | 8 | "x ¿" | 9 | "x «" | 10 | endl; 4666 \end{ lstlisting}4666 \end{cfa} 4667 4667 %$ 4668 \begin{ lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]4668 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 4669 4669 x (1 x [2 x {3 x =4 x $5 x £6 x ¥7 x ¡8 x ¿9 x «10 4670 \end{ lstlisting}4670 \end{cfa} 4671 4671 %$ 4672 4672 \item 4673 4673 {\lstset{deletedelim=**[is][]{¢}{¢}} 4674 4674 A seperator does not appear after a C string ending with the (extended) \Index{ASCII}\index{ASCII!extended} characters: ©,.:;!?)]}%¢»© 4675 \begin{ lstlisting}[belowskip=0pt]4675 \begin{cfa}[belowskip=0pt] 4676 4676 sout | 1 | ", x" | 2 | ". x" | 3 | ": x" | 4 | "; x" | 5 | "! x" | 6 | "? x" | 7 | "% x" 4677 4677 | 8 | "¢ x" | 9 | "» x" | 10 | ") x" | 11 | "] x" | 12 | "} x" | endl; 4678 \end{ lstlisting}4679 \begin{ lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]4678 \end{cfa} 4679 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 4680 4680 1, x 2. x 3: x 4; x 5! x 6? x 7% x 8¢ x 9» x 10) x 11] x 12} x 4681 \end{ lstlisting}}%4681 \end{cfa}}% 4682 4682 \item 4683 4683 A seperator does not appear before or after a C string begining/ending with the \Index{ASCII} quote or whitespace characters: \lstinline[showspaces=true]@`'" \t\v\f\r\n@ 4684 \begin{ lstlisting}[belowskip=0pt]4684 \begin{cfa}[belowskip=0pt] 4685 4685 sout | "x`" | 1 | "`x'" | 2 | "'x\"" | 3 | "\"x" | "x " | 4 | " x" | "x\t" | 1 | "\tx" | endl; 4686 \end{ lstlisting}4687 \begin{ lstlisting}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt]4686 \end{cfa} 4687 \begin{cfa}[mathescape=off,showspaces=true,showtabs=true,aboveskip=0pt,belowskip=0pt] 4688 4688 x`1`x'2'x"3"x x 4 x x 1 x 4689 \end{ lstlisting}4689 \end{cfa} 4690 4690 \end{enumerate} 4691 4691 The following \CC-style \Index{manipulator}s allow further control over implicit seperation. 4692 \begin{ lstlisting}[mathescape=off,belowskip=0pt]4692 \begin{cfa}[mathescape=off,belowskip=0pt] 4693 4693 sout | sepOn | 1 | 2 | 3 | sepOn | endl; §\C{// separator at start of line}§ 4694 \end{ lstlisting}4695 \begin{ lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]4694 \end{cfa} 4695 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 4696 4696 1 2 3 4697 \end{ lstlisting}4698 \begin{ lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]4697 \end{cfa} 4698 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] 4699 4699 sout | 1 | sepOff | 2 | 3 | endl; §\C{// turn off implicit separator locally}§ 4700 \end{ lstlisting}4701 \begin{ lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]4700 \end{cfa} 4701 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 4702 4702 12 3 4703 \end{ lstlisting}4704 \begin{ lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]4703 \end{cfa} 4704 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] 4705 4705 sout | sepDisable | 1 | 2 | 3 | endl; §\C{// turn off implicit separation globally}§ 4706 \end{ lstlisting}4707 \begin{ lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]4706 \end{cfa} 4707 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 4708 4708 123 4709 \end{ lstlisting}4710 \begin{ lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]4709 \end{cfa} 4710 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] 4711 4711 sout | 1 | sepOn | 2 | 3 | endl; §\C{// turn on implicit separator locally}§ 4712 \end{ lstlisting}4713 \begin{ lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]4712 \end{cfa} 4713 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 4714 4714 1 23 4715 \end{ lstlisting}4716 \begin{ lstlisting}[mathescape=off,aboveskip=0pt,belowskip=0pt]4715 \end{cfa} 4716 \begin{cfa}[mathescape=off,aboveskip=0pt,belowskip=0pt] 4717 4717 sout | sepEnable | 1 | 2 | 3 | endl; §\C{// turn on implicit separation globally}§ 4718 \end{ lstlisting}4719 \begin{ lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt]4718 \end{cfa} 4719 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt,belowskip=0pt] 4720 4720 1 2 3 4721 \end{ lstlisting}4722 \begin{ lstlisting}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt]4721 \end{cfa} 4722 \begin{cfa}[mathescape=off,aboveskip=0pt,aboveskip=0pt,belowskip=0pt] 4723 4723 sepSet( sout, ", $" ); §\C{// change separator from " " to ", \$"}§ 4724 4724 sout | 1 | 2 | 3 | endl; 4725 \end{ lstlisting}4725 \end{cfa} 4726 4726 %$ 4727 \begin{ lstlisting}[mathescape=off,showspaces=true,aboveskip=0pt]4727 \begin{cfa}[mathescape=off,showspaces=true,aboveskip=0pt] 4728 4728 1, $2, $3 4729 \end{ lstlisting}4729 \end{cfa} 4730 4730 %$ 4731 4731 \begin{comment} … … 4769 4769 4770 4770 \leavevmode 4771 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]4771 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 4772 4772 forall( otype T ) T * malloc( void );§\indexc{malloc}§ 4773 4773 forall( otype T ) T * malloc( char fill ); … … 4784 4784 forall( otype T ) T * memset( T * ptr, unsigned char fill ); // use default value '\0' for fill 4785 4785 forall( otype T ) T * memset( T * ptr ); // remove when default value available 4786 \end{ lstlisting}4786 \end{cfa} 4787 4787 4788 4788 … … 4790 4790 4791 4791 \leavevmode 4792 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]4792 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 4793 4793 int ato( const char * ptr );§\indexc{ato}§ 4794 4794 unsigned int ato( const char * ptr ); … … 4816 4816 double _Complex strto( const char * sptr, char ** eptr ); 4817 4817 long double _Complex strto( const char * sptr, char ** eptr ); 4818 \end{ lstlisting}4818 \end{cfa} 4819 4819 4820 4820 … … 4822 4822 4823 4823 \leavevmode 4824 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]4824 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 4825 4825 forall( otype T | { int ?<?( T, T ); } ) 4826 4826 T * bsearch( const T key, const T * arr, size_t dimension );§\indexc{bsearch}§ … … 4828 4828 forall( otype T | { int ?<?( T, T ); } ) 4829 4829 void qsort( const T * arr, size_t dimension );§\indexc{qsort}§ 4830 \end{ lstlisting}4830 \end{cfa} 4831 4831 4832 4832 … … 4834 4834 4835 4835 \leavevmode 4836 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]4836 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 4837 4837 char abs( char );§\indexc{abs}§ 4838 4838 int abs( int ); … … 4845 4845 double abs( double _Complex ); 4846 4846 long double abs( long double _Complex ); 4847 \end{ lstlisting}4847 \end{cfa} 4848 4848 4849 4849 … … 4851 4851 4852 4852 \leavevmode 4853 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]4853 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 4854 4854 void rand48seed( long int s );§\indexc{rand48seed}§ 4855 4855 char rand48();§\indexc{rand48}§ … … 4863 4863 double _Complex rand48(); 4864 4864 long double _Complex rand48(); 4865 \end{ lstlisting}4865 \end{cfa} 4866 4866 4867 4867 … … 4869 4869 4870 4870 \leavevmode 4871 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]4871 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 4872 4872 forall( otype T | { int ?<?( T, T ); } ) 4873 4873 T min( const T t1, const T t2 );§\indexc{min}§ … … 4881 4881 forall( otype T ) 4882 4882 void swap( T * t1, T * t2 );§\indexc{swap}§ 4883 \end{ lstlisting}4883 \end{cfa} 4884 4884 4885 4885 … … 4893 4893 4894 4894 \leavevmode 4895 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]4895 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 4896 4896 float fabs( float );§\indexc{fabs}§ 4897 4897 double fabs( double ); … … 4937 4937 double nan( const char * ); 4938 4938 long double nan( const char * ); 4939 \end{ lstlisting}4939 \end{cfa} 4940 4940 4941 4941 … … 4943 4943 4944 4944 \leavevmode 4945 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]4945 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 4946 4946 float exp( float );§\indexc{exp}§ 4947 4947 double exp( double ); … … 4994 4994 double logb( double ); 4995 4995 long double logb( long double ); 4996 \end{ lstlisting}4996 \end{cfa} 4997 4997 4998 4998 … … 5000 5000 5001 5001 \leavevmode 5002 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]5002 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 5003 5003 float sqrt( float );§\indexc{sqrt}§ 5004 5004 double sqrt( double ); … … 5022 5022 double _Complex pow( double _Complex, double _Complex ); 5023 5023 long double _Complex pow( long double _Complex, long double _Complex ); 5024 \end{ lstlisting}5024 \end{cfa} 5025 5025 5026 5026 … … 5028 5028 5029 5029 \leavevmode 5030 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]5030 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 5031 5031 float sin( float );§\indexc{sin}§ 5032 5032 double sin( double ); … … 5078 5078 double atan( double, double );§\indexc{atan}§ 5079 5079 long double atan( long double, long double ); 5080 \end{ lstlisting}5080 \end{cfa} 5081 5081 5082 5082 … … 5084 5084 5085 5085 \leavevmode 5086 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]5086 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 5087 5087 float sinh( float );§\indexc{sinh}§ 5088 5088 double sinh( double ); … … 5126 5126 double _Complex atanh( double _Complex ); 5127 5127 long double _Complex atanh( long double _Complex ); 5128 \end{ lstlisting}5128 \end{cfa} 5129 5129 5130 5130 … … 5132 5132 5133 5133 \leavevmode 5134 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]5134 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 5135 5135 float erf( float );§\indexc{erf}§ 5136 5136 double erf( double ); … … 5157 5157 double tgamma( double ); 5158 5158 long double tgamma( long double ); 5159 \end{ lstlisting}5159 \end{cfa} 5160 5160 5161 5161 … … 5163 5163 5164 5164 \leavevmode 5165 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]5165 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 5166 5166 float floor( float );§\indexc{floor}§ 5167 5167 double floor( double ); … … 5211 5211 long long int llround( double ); 5212 5212 long long int llround( long double ); 5213 \end{ lstlisting}5213 \end{cfa} 5214 5214 5215 5215 … … 5217 5217 5218 5218 \leavevmode 5219 \begin{ lstlisting}[aboveskip=0pt,belowskip=0pt]5219 \begin{cfa}[aboveskip=0pt,belowskip=0pt] 5220 5220 float copysign( float, float );§\indexc{copysign}§ 5221 5221 double copysign( double, double ); … … 5252 5252 double scalbln( double, long int ); 5253 5253 long double scalbln( long double, long int ); 5254 \end{ lstlisting}5254 \end{cfa} 5255 5255 5256 5256 … … 5261 5261 When creating and computing with rational numbers, results are constantly reduced to keep the numerator and denominator as small as possible. 5262 5262 5263 \begin{ lstlisting}[belowskip=0pt]5263 \begin{cfa}[belowskip=0pt] 5264 5264 // implementation 5265 5265 struct Rational {§\indexc{Rational}§ … … 5304 5304 forall( dtype istype | istream( istype ) ) istype * ?|?( istype *, Rational * ); 5305 5305 forall( dtype ostype | ostream( ostype ) ) ostype * ?|?( ostype *, Rational ); 5306 \end{ lstlisting}5306 \end{cfa} 5307 5307 5308 5308
Note: See TracChangeset
for help on using the changeset viewer.
