Changeset a514fed
- Timestamp:
- Apr 11, 2025, 6:40:42 PM (6 months ago)
- Branches:
- master
- Children:
- 5ad6f0d
- Parents:
- 30548de
- Location:
- doc/user
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/user/Makefile
r30548de ra514fed 46 46 47 47 all : ${DOCUMENT} 48 49 INSTALLDOCDIR = /u/cforall/public_html/doc 50 install : all ${INSTALLDOCDIR} 51 cp -f ${DOCUMENT} ${INSTALLDOCDIR}/${DOCUMENT} 48 52 49 53 clean : -
doc/user/user.tex
r30548de ra514fed 11 11 %% Created On : Wed Apr 6 14:53:29 2016 12 12 %% Last Modified By : Peter A. Buhr 13 %% Last Modified On : Fri Jan 17 14:20:39202514 %% Update Count : 697113 %% Last Modified On : Fri Apr 11 18:33:42 2025 14 %% Update Count : 7064 15 15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 16 16 … … 597 597 This extension is backwards compatible, matches with the use of underscore in variable names, and appears in \Index*{Ada} and \Index*{Java} 8. 598 598 \CC uses the single quote (©'©) as a separator, restricted within a sequence of digits, \eg ©0xaa©©'©©ff©, ©3.141©©'©©592E1©©'©©1©. 599 However, the drawback of the \CC approach is diff icults parsing for IDEs between character and numeric constants, as quotes are no longer balanced (©'x'© and ©3.14©©'©©159©).599 However, the drawback of the \CC approach is differentiating between character and numeric constants by IDEs, as quotes are no longer balanced (©'x'© and ©3.14©©'©©159©). 600 600 601 601 602 602 \section{Exponentiation Operator} 603 603 604 C, \CC, and Java (and other programming languages) have \emph{no} exponentiation operator\index{exponentiation!operator}\index{operator!exponentiation}, \ie $x^y$, and instead use a routine, like \Indexc{pow(x,y)}, to perform the exponentiation operation. 605 \CFA extends the basic operators with the exponentiation operator ©?©\R{©\\©}©?©\index{?\\?@©?@\@?©} and ©?©\R{©\\©}©=?©\index{?\\=?@©@\@=?©}, as in, ©x ©\R{©\\©}© y© and ©x ©\R{©\\©}©= y©, which means $x^y$ and $x \leftarrow x^y$. 604 Exponentiation, $x^y$, means raise $x$ to the $y$th power. 605 When $y$ is a positive integer, exponentiation corresponds to $\prod_{i=1}^{y} x$. 606 607 C, \CC, Java and other programming languages have no exponentiation operator\index{exponentiation!operator}\index{operator!exponentiation}, using a routine like \Indexc{pow( x, y )} instead. 608 Ada, Haskell, Python and other programming languages often use operators ©^© or ©**© for exponentiation. 609 However, neither of these operators work in C as ©^© means exclusive-or and ©**© means double dereference. 610 Furthermore, using a routine for exponentiation does not match with mathematical expectation, \ie ©-x**-y© becomes ©pow( -x, -y )©. 611 612 \CFA extends the basic C operator set with symbol \R{©\\©} (backslash) as the exponentiation operator, represented by routines ©?©\R{©\\©}©?©\index{?\\?@©?@\@?©} and ©?©\R{©\\©}©=?©\index{?\\=?@©@\@=?©}, respectively. 613 For example, ©x ©\R{©\\©}© y© and ©x ©\R{©\\©}©= y© mean $x^y$ and $x \leftarrow x^y$. 606 614 The priority of the exponentiation operator is between the cast and multiplicative operators, so ©-f(x) \ -g(y)© is parenthesized as ©(-f(x)) \ (-g(y))©. 607 608 There are exponentiation operators for integral and floating types, including the builtin \Index{complex} types. 609 Integral exponentiation\index{exponentiation!unsigned integral} is performed with repeated multiplication ($O(\log y)$ or shifting if the exponent is 2). 615 The C ©pow© routines continues to be available for backwards compatibility. 616 617 Exponentiation is overloaded for integral and floating types, including the builtin \Index{complex} types. 618 Integral exponentiation\index{exponentiation!unsigned integral} is performed with repeated multiplication ($O(\log y)$ or shifting if the exponent is 2. 610 619 Overflow for a large exponent or negative exponent returns zero. 611 620 Floating exponentiation\index{exponentiation!floating} is performed using \Index{logarithm}s\index{exponentiation!logarithm}, so the exponent cannot be negative. … … 615 624 \end{cfa} 616 625 Note, ©5 \ 32© and ©5L \ 64© overflow, and ©-4 \ -3© is a fraction but stored in an integer so all three computations generate an integral zero. 617 Because exponentiation has higher priority than ©+©, parenthesis are necessaryfor exponentiation of \Index{complex constant}s or the expression is parsed as ©1.0f+©\R{©(©}©2.0fi \ 3.0f©\R{©)©}©+2.0fi©, requiring \R{©(©}©1.0f+2.0fi©\R{©)©}© \ ©\R{©(©}©3.0f+2.0fi©\R{©)©}.626 Because exponentiation has higher priority than ©+©, parenthesis are required for exponentiation of \Index{complex constant}s or the expression is parsed as ©1.0f+©\R{©(©}©2.0fi \ 3.0f©\R{©)©}©+2.0fi©, requiring \R{©(©}©1.0f+2.0fi©\R{©)©}© \ ©\R{©(©}©3.0f+2.0fi©\R{©)©}. 618 627 619 628 The exponentiation operator is available for all the basic types, but for user-defined types, only the integral-computation version is available. … … 624 633 T ?®\®?( T ep, unsigned long int y ); 625 634 \end{cfa} 626 A user type ©T© must define one (©1©) ,and multiplication (©*©) \see{\VRef{s:Operator}}.635 A user type ©T© must define one (©1©) and multiplication (©*©) \see{\VRef{s:Operator}}. 627 636 628 637 … … 638 647 Declarations in the \Indexc{do}-©while© condition are not useful because they appear after the loop body.} 639 648 \begin{cfa} 640 if ( ®int x = f()® ) ... §\C {// x != 0}§649 if ( ®int x = f()® ) ... §\C[2.75in]{// x != 0}§ 641 650 if ( ®int x = f(), y = g()® ) ... §\C{// x != 0 \&\& y != 0}§ 642 651 if ( ®int x = f(), y = g(); x < y® ) ... §\C{// relational expression}§ … … 646 655 while ( ®int x = f(), y = g()® ) ... §\C{// x != 0 \&\& y != 0}§ 647 656 while ( ®int x = f(), y = g(); x < y® ) ... §\C{// relational expression}§ 648 while ( ®struct S { int i; } x = { f() }; x.i < 4® ) ... §\C{// relational expression} §657 while ( ®struct S { int i; } x = { f() }; x.i < 4® ) ... §\C{// relational expression}\CRT§ 649 658 \end{cfa} 650 659 Unless a relational expression is specified, each variable is compared not equal to 0, which is the standard semantics for the ©if©/©while© expression, and the results are combined using the logical \Indexc{&&} operator. … … 692 701 \end{tabular} 693 702 \end{cquote} 694 In addition, subranges are allowed to specify a contiguous set of case values.703 In addition, inclusive ranges are allowed using symbol ©~© to specify a contiguous set of case values, both positive and negative. 695 704 \begin{cquote} 696 \begin{tabular}{@{}l@{\hspace{3em}}l@{\hspace{2em}}l@{\hspace{2em}}l@{}} 697 \multicolumn{1}{c@{\hspace{3em}}}{\textbf{C}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{\CFA}} & \multicolumn{1}{c@{\hspace{2em}}}{\textbf{©gcc©}} \\ 705 \setlength{\tabcolsep}{15pt} 706 \begin{tabular}{@{}llll@{}} 707 \multicolumn{1}{c}{\textbf{C}} & \multicolumn{1}{c}{\textbf{\CFA}} & \multicolumn{1}{c}{\textbf{©gcc©}} \\ 698 708 \begin{cfa} 699 709 switch ( i ) { 700 case 1: case 2: case 3: case 4:710 case -4: case -3: case -2: case -1: 701 711 ... 702 712 case 10: case 11: case 12: case 13: … … 707 717 \begin{cfa} 708 718 switch ( i ) { 709 case ® 1~4:®719 case ®-4~-1:® 710 720 ... 711 721 case ®10~13:® … … 716 726 \begin{cfa} 717 727 switch ( i ) { 718 case 1§\R{\textvisiblespace}§®...®4:728 case -4§\R{\textvisiblespace}§®...®-1: 719 729 ... 720 730 case 10§\R{\textvisiblespace}§®...®13: … … 725 735 \begin{cfa} 726 736 727 // 1, 2, 3, 4737 // -4, -3, -2, -1 728 738 729 739 // 10, 11, 12, 13 … … 733 743 \end{tabular} 734 744 \end{cquote} 735 While ©gcc© has the same range mechanism, it has an awkward syntax, ©2©\R{\textvisiblespace}©...42©, because a space is required after a number, otherwise the period is a decimal point.745 While ©gcc© has the same range mechanism, it has an awkward syntax, ©2©\R{\textvisiblespace}©...42©, because a space is required after the lower bound, otherwise the period is a decimal point. 736 746 737 747 \CFA also allows lists of subranges. 738 748 \begin{cfa} 739 case ® 1~5, 12~21, 35~42®:749 case ®-5~-1, 12~21, 35~42®: 740 750 \end{cfa} 741 751 … … 807 817 808 818 While fall-through itself is not a problem, the problem occurs when fall-through is the default, as this semantics is unintuitive for many programmers and is different from most programming languages with a ©switch© statement. 809 Hence, default fall-through semantics results in programmingerrors as programmers often \emph{forget} the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through.819 Hence, default fall-through semantics results in errors as programmers often \emph{forget} the ©break© statement at the end of a ©case© clause, resulting in inadvertent fall-through. 810 820 811 821 \item … … 820 830 } // if 821 831 \end{cfa} 822 This usage branches into control structures, which is known to cause bothcomprehension and technical difficulties.832 This usage branches into control structures, which causes comprehension and technical difficulties. 823 833 The comprehension problem results from the inability to determine how control reaches a particular point due to the number of branches leading to it. 824 834 The technical problem results from the inability to ensure declaration and initialization of variables when blocks are not entered at the beginning. 825 835 There are few arguments for this kind of control flow, and therefore, there is a strong impetus to eliminate it. 826 This C idiom is known as ``\Index*{Duff's device}''~\cite{Duff83}, from th isexample:836 This C idiom is known as ``\Index*{Duff's device}''~\cite{Duff83}, from the example: 827 837 \begin{cfa} 828 838 register int n = (count + 7) / 8; … … 1056 1066 That is, the optional low set value, the optional scan direction (ascending/descending), the (possibly) required range character, the optional include last-scan value, the required high set value, and the optional range character and step value. 1057 1067 \R{Warning}: the regular expression allows the form ©~H©, but this syntax has a preexisting meaning in C: complement the bits of ©H©, \eg ©for ( ~5 )© meaning ©for ( -6 )©, as ©-6© is the complement of ©5©. 1058 This anomaly is unlikely to cause problems because programers willwrite the shorter ©for ( 5 )©.1068 This anomaly is unlikely to cause problems because programers should write the shorter ©for ( 5 )©. 1059 1069 1060 1070 The previous ©for© loops have an anonymous loop index in which the range iteration is computed. … … 2948 2958 Specifically, the inheritance relationship for ©Name©s is: 2949 2959 \begin{cfa} 2950 Name $\(\subseteq\)$ Name2 $\(\subseteq\)$ Name3 $\(\subseteq\)$const char * // enum type of Name2960 Name §\(\subseteq\)§ Name2 §\(\subseteq\)§ Name3 §\(\subseteq\)§ const char * // enum type of Name 2951 2961 \end{cfa} 2952 2962 Hence, given … … 3990 4000 \subsection{Casting} 3991 4001 3992 In C, the cast operator is used to explicitly convert between types. 4002 Casting is a mechanism to explicitly change the type and representation of a value. 4003 If the type and representation are changed, the cast is a \newterm{conversion}; 4004 if only the type is changed but not the value representation, the cast is a \newterm{coercion}. 4005 For example, in: 4006 \begin{cfa} 4007 int i, *ip; 4008 double d; 4009 d = (double)i; §\C{// conversion}§ 4010 ip = (int *)d; §\C{// coercion}§ 4011 \end{cfa} 4012 the conversion cast implicitly runs code that transforms an integer representation into the best-effort floating-point representation. 4013 Another conversion case exists in object-oriented programming-languages to walk an inheritence hierarchy looking for specific types along the path. 4014 The coercion cast lies about the representation of the value as the integer point is actually pointing at a floating-point value; 4015 indirect operations through ©ip© are as odds with direct operations on ©d©. 4016 In general, coercion casts are only necessary for systems programming, like building a memory allocator, where raw storage is typed and returned for use by the language or the runtime system to access storage in special ways. 4017 4018 For coercion casts, there are often fine-grain variations to precisely expalin how the storage is to be typed. 4019 \CC and \CFA have a number specialized casts., there are four types of explicit casting operators. 4020 \begin{enumerate} 4021 \item 4022 ©dynamic_cast© Used for conversion of polymorphic types. 4023 \item 4024 ©static_cast© Used for conversion of nonpolymorphic types. 4025 \item 4026 ©const_cast© Used to remove the type qualifiers and possibly attributes. 4027 \item 4028 ©reinterpret_cast© Used for simple reinterpretation of bits. 4029 \end{enumerate} 4030 4031 \begin{cfa} 4032 '(' type_no_function ')' cast_expression 4033 '(' aggregate_control '&' ')' cast_expression // CFA 4034 '(' aggregate_control '*' ')' cast_expression // CFA 4035 '(' VIRTUAL ')' cast_expression // CFA 4036 '(' VIRTUAL type_no_function ')' cast_expression // CFA 4037 '(' RETURN type_no_function ')' cast_expression // CFA (ASCRIPTION) 4038 '(' COERCE type_no_function ')' cast_expression // CFA (COERCION) 4039 '(' qualifier_cast_list ')' cast_expression // CFA, (modify CVs of cast_expression) 4040 \end{cfa} 4041 4042 4043 Specialized Casts 4044 4045 There is some use in Cforall for cast operators with semantics other than the standard C cast. 4046 To make these alternate casts look like the familiar C cast, this proposal follows the example of the virtual proposal's virtual cast `(virtual Foo)x` and uses an added (pseudo-)keyword inside the cast parens. 4047 4048 C (Conversion) Cast 4049 4050 The standard C cast performs conversions, transformations between types which may make a new object with a different in-memory representation. 4051 Cforall maintains these semantics in a backward-compatible way while accounting for name overloading by choosing the lowest-cost interpretation of the argument expression which is convertable to the target type, breaking ties by conversion cost. 4052 4053 The C cast must be maintained for backward-compatibility, and developing a second cast operator with identical semantics seems an undesirable multiplication of language features, but `(convert Foo)` or `(to Foo)` would be reasonable options for a keyword. 4054 An alternate semantics for a Cforall-specific conversion cast would be to choose the cast interpretation with the lowest sum of conversion cost and interpretation cost, which aligns better with Cforall function call resolution algorithm. 4055 4056 Ascription Cast 4057 4058 Using casts in Cforall for type ascription ("select the interpretation of this type") works by the conversion-cost tiebreaker behaviour of the cast operator. 4059 However, the ascription interpretation of casts is prioritized less than the conversion interpretation of casts, sometimes resulting in some surprising results, as in the following example: 4060 \begin{cfa} 4061 int f(int); // f1 4062 int f(double); // f2 4063 int g(int); // g1 4064 double g(long); // g2 4065 4066 f((double)42); // selects f2 by cast on argument 4067 (double)g(42); // does NOT select g2, argument conversion cost results in g1 4068 \end{cfa} 4069 An ascription cast which reversed the priorities of the C cast would be useful for selecting expressions based on their return type; a reversal of the priorities of the standard C cast would work for this (that is, select the lowest-cost conversion, breaking ties based on argument cost). 4070 A plausible stricter semantics would be to select the cheapest interpretation with a zero-cost conversion to the target type, reporting a compiler error otherwise (this semantics would make ascription a solely compile-time phenomenon, rather than relying on possible runtime conversions). 4071 A resonable keyword would be `(as Foo)`, which is short, evocative, and echos "ascription"; `(return Foo)` would not introduce new keywords, and speaks to its use in return-type selection, as in the following corrected version of the example above: 4072 \begin{cfa} 4073 (as double)g(42); // selects g2, as expected (under either presented ascription semantics) 4074 \end{cfa} 4075 4076 Coercion Cast 4077 4078 Some of the explict conversions in C are defined to be a coercions (reinterpret the bits of this value as another type). 4079 Use of coercions often relies on non-standard implementation details of the provided environment, and as such is discouraged, but is sometimes necessary. 4080 Since all explicit pointer casts in C are coercions, any lvalue ©x© in C/Cforall can be coerced with the pattern ©*(Foo*)&x©, but this is complex and doesn't extend to rvalues. 4081 \begin{cfa} 4082 int i = 5; 4083 double d = *(double*)&i; // value coercion 4084 printf( "%g %g %x\n", d, *(double *)&i, *(int *)&d ); 4085 4086 int i = 5; // pointer coercion 4087 double d = *(double*)&i; // value coercion 4088 \end{cfa} 4089 A dedicated coercion cast would solve these issues; ©(reinterpret Foo)© (from C++), ©(transmute Foo)© (from Rust), or ©(coerce Foo)© would be reasonable keywords. 4090 4091 Qualifier Cast 4092 4093 A more restricted (and thus safer) form of coercion is modifiying the qualifiers of a type; C++ has ©const_cast© for this purpose, and a similar feature would be useful for Cforall. 4094 With regard to syntax, ©(requalify const Foo)©/©(requalify Foo)© to add/strip ©const© would echo C++, but given that the vast majority of uses are stripping const-qualfiers, ©(non const)© would be shorter, clearer, easily searchable, and not require the programmer to exactly match the argument type. 4095 In this syntax, coercion casts could be used to add qualifiers, or another cast type (say ©(with const)©) could be introduced to add qualfiers. 4096 4097 Virtual Cast 4098 see virtual.txt; semantics equivalent to C++ dynamic cast 4099 4100 3993 4101 In \CFA, the cast operator has a secondary use, which is type ascription, since it forces the expression resolution algorithm to choose the lowest cost conversion to the target type. 3994 4102 That is, a cast can be used to select the type of an expression when it is ambiguous, as in the call to an overloaded function. … … 4037 4145 If ©g© is free of side effects, this is equivalent to ©[(int)(g().0), (int)(g().1.0), (int)(g().2)]©. 4038 4146 Since ©void© is effectively a 0-element tuple, (3) discards the first and third return values, which is effectively equivalent to ©[(int)(g().1.0), (int)(g().1.1)]©). 4039 % will this always hold true? probably, as constructors should give all of the conversion power we need. if casts become function calls, what would they look like? would need a way to specify the target type, which seems awkward. Also, C++ basically only has this because classes are closed to extension, while we don't have that problem (can have floating constructors for any type). 4147 % will this always hold true? probably, as constructors should give all of the conversion power we need. 4148 if casts become function calls, what would they look like? would need a way to specify the target type, which seems awkward. 4149 Also, C++ basically only has this because classes are closed to extension, while we don't have that problem (can have floating constructors for any type). 4040 4150 Note that a cast is not a function call in \CFA, so flattening and structuring conversions do not occur for cast expressions. 4041 4151 As such, (4) is invalid because the cast target type contains 4 components, while the source type contains only 3. … … 4193 4303 g( w2 ); 4194 4304 \end{cfa} 4195 Note, in all cases 3 arguments are supplied even though the syntax may appear to supply less than 3. As mentioned, a4196 tuple does not have structure like a record; a tuple is simply converted into a list of components.4305 Note, in all cases 3 arguments are supplied even though the syntax may appear to supply less than 3. 4306 As mentioned, a tuple does not have structure like a record; a tuple is simply converted into a list of components. 4197 4307 \begin{rationale} 4198 4308 The present implementation of \CFA does not support nested routine calls when the inner routine returns multiple values; \ie a statement such as ©g( f() )© is not supported. … … 5300 5410 5301 5411 \item 5302 \Indexc{quote d}( ©char & ch©, ©const char Ldelimiter = '\''©, ©const char Rdelimiter = '\0'© )\index{manipulator!quoted@©quoted©}5412 \Indexc{quote}( ©char & ch©, ©const char Ldelimiter = '\''©, ©const char Rdelimiter = '\0'© )\index{manipulator!quote@©quote©} 5303 5413 consumes the string ©"LCR"©, where ©L© is the left ©delimiter© character, ©C© is the value in ©ch©, and ©R© is the right delimiter character, which skips whitespace, consumes and ignores the left delimiter, reads a single character into ©ch©, and consumes and ignores the right delimiter (3 characters). 5304 5414 If the delimit character is omitted, it defaults to ©'\''© (single quote). 5305 5415 \begin{cfa}[belowskip=0pt] 5306 5416 char ch; 5307 sin | quote d( ch ); sin | quoted( ch, '"' ); sin | quoted( ch, '[', ']' );5417 sin | quote( ch ); sin | quote( ch, '"' ); sin | quote( ch, '[', ']' ); 5308 5418 \end{cfa} 5309 5419 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt] … … 5313 5423 \item 5314 5424 \begin{sloppypar} 5315 \Indexc{quote d}( $wdi\ manipulator$, ©const char Ldelimiter = '\''©, ©const char Rdelimiter = '\0'© )\index{manipulator!quoted@©quoted©}5425 \Indexc{quote}( $wdi\ manipulator$, ©const char Ldelimiter = '\''©, ©const char Rdelimiter = '\0'© )\index{manipulator!quote@©quote©} 5316 5426 consumes the scanset ©"L[^R]R"©, where ©L© is the left ©delimiter© character and ©R© is the right delimiter character, which skips whitespace, consumes and ignores the left delimiter, reads characters until the right-delimiter into the string variable (null terminated), and consumes and ignores the right delimiter. 5317 If the delimit character is omitted, it defaults to ©' \''© (single quote).5427 If the delimit character is omitted, it defaults to ©'"'© (double quote). 5318 5428 \end{sloppypar} 5319 5429 \begin{cfa}[belowskip=0pt] 5320 5430 char cs[10]; 5321 sin | quote d( wdi( sizeof(cs), cs ) ); §\C[3in]{// " is the start/end delimiter}§5322 sin | quote d( wdi( sizeof(cs), cs ), '\'' ); §\C{// ' is the start/end delimiter}§5323 sin | quote d( wdi( sizeof(cs), cs ), '[', ']' ); §\C{// [ is the start and ] is the end delimiter}\CRT§5431 sin | quote( wdi( sizeof(cs), cs ) ); §\C[3in]{// " is the start/end delimiter}§ 5432 sin | quote( wdi( sizeof(cs), cs ), '\'' ); §\C{// ' is the start/end delimiter}§ 5433 sin | quote( wdi( sizeof(cs), cs ), '[', ']' ); §\C{// [ is the start and ] is the end delimiter}\CRT§ 5324 5434 \end{cfa} 5325 5435 \begin{cfa}[showspaces=true] … … 5357 5467 sin | ignore( d ); §\C{// d is unchanged}§ 5358 5468 sin | ignore( cs ); §\C{// cs is unchanged, no wdi required}§ 5359 sin | ignore( quote d( wdi( sizeof(cs), cs ) ) ); §\C{// cs is unchanged}§5469 sin | ignore( quote( wdi( sizeof(cs), cs ) ) ); §\C{// cs is unchanged}§ 5360 5470 \end{cfa} 5361 5471 \begin{cfa}[showspaces=true,aboveskip=0pt,belowskip=0pt] … … 5794 5904 In \CFA, as in C, all scalar types can be incremented and 5795 5905 decremented, which is defined in terms of adding or subtracting 1. 5796 The operations ©&&©, ©||©, and ©!© can be applied to any scalar arguments and are defined in terms of comparison against 0 ( ex.©(a && b)© becomes ©(a != 0 && b != 0)©).5906 The operations ©&&©, ©||©, and ©!© can be applied to any scalar arguments and are defined in terms of comparison against 0 (\eg ©(a && b)© becomes ©(a != 0 && b != 0)©). 5797 5907 5798 5908 In C, the integer constants 0 and 1 suffice because the integer promotion rules can convert them to any arithmetic type, and the rules for pointer expressions treat constant expressions evaluating to 0 as a special case. … … 5800 5910 Defining special constants for a user-defined type is more efficient than defining a conversion to the type from ©bool©. 5801 5911 5802 Why just 0 and 1? Why not other integers? No other integers have special status in C. 5803 A facility that let programmers declare specific constants..const Rational 12., for instance. would not be much of an improvement. 5912 Why just 0 and 1? 5913 Why not other integers? 5914 No other integers have special status in C. 5915 A facility that let programmers declare specific constants ©const Rational 12©, for instance. would not be much of an improvement. 5804 5916 Some facility for defining the creation of values of programmer-defined types from arbitrary integer tokens would be needed. 5805 5917 The complexity of such a feature does not seem worth the gain. 5806 5918 5807 5919 For example, to define the constants for a complex type, the programmer would define the following: 5808 5809 5920 \begin{cfa} 5810 5921 struct Complex { … … 6525 6636 For example, container/vector is a valid module name, where container is the parent module name, and vector is the sub-module under container. 6526 6637 6527 Only the interfaces of a module are visible from outside, when the module is imported .export is a type decorator to declare a module interface.6638 Only the interfaces of a module are visible from outside, when the module is imported, export is a type decorator to declare a module interface. 6528 6639 A method, a global variable or a type can be declared as a module interface. 6529 6640 Types defined in a module and referenced by an exported function or a variable must be exported, too. … … 6558 6669 All of the exported names are visible in the file that imports the module. 6559 6670 The exported names can be accessed within a namespace based on the module name in the first syntax (ex moduleName.foo). 6560 If moduleName has several elements separated by '/' to describe a sub-module ( ex.import container/vector;), the last element in the moduleName is used as the namespace to access the visible names in that module (ex vector.add(...);).6561 The as keyword is used to confine the imported names in a unique namespace ( ex.anotherName.foo). anotherName must be a valid identifier (same rules as a variable name) which means it cannot have '/' in it.6671 If moduleName has several elements separated by '/' to describe a sub-module (\eg import container/vector;), the last element in the moduleName is used as the namespace to access the visible names in that module (ex vector.add(...);). 6672 The as keyword is used to confine the imported names in a unique namespace (\eg anotherName.foo). anotherName must be a valid identifier (same rules as a variable name) which means it cannot have '/' in it. 6562 6673 Conflicts in namespaces will be reported by the compiler. 6563 6674 The second method can be used to solve conflicting name problems. … … 6582 6693 6583 6694 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. 6584 6585 6695 \begin{cfa} 6586 6696 module M1;
Note:
See TracChangeset
for help on using the changeset viewer.