Ignore:
Timestamp:
Apr 28, 2024, 3:49:00 PM (8 months ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
master
Children:
5c27b6a, caaf424
Parents:
e78966e
Message:

more proofreading on enumeration chapters

Location:
doc/theses/jiada_liang_MMath
Files:
4 edited

Legend:

Unmodified
Added
Removed

  • doc/theses/jiada_liang_MMath/CFAenum.tex

    re78966e rf632117  
    44\CFA supports C enumeration using the same syntax and semantics for backwards compatibility.
    55\CFA also extends C-Style enumeration by adding a number of new features that bring enumerations inline with other modern programming languages.
    6 
    7 
    8 \section{Enumerator Name Resolution}
    9 \label{s:EnumeratorNameResolution}
    10 
    11 In C, unscoping of enumerators presents a \Newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names.
    12 There is no mechanism in C to resolve these naming conflicts other than renaming of one of the duplicates, which may be impossible.
     6Any enumeration extensions must be intuitive to C programmers both in syntax and semantics.
     7The following sections detail all of my new contributions to enumerations in \CFA.
     8
     9
     10\section{Aliasing}
     11
     12C already provides @const@-style aliasing using the unnamed enumerator \see{\VRef{s:TypeName}}, even if the name @enum@ is misleading (@const@ would be better).
     13Given the existence of this form, it is straightforward to extend it with types other than integers.
     14\begin{cfa}
     15enum E { Size = 20u, PI = 3.14159L, Jack = L"John" };
     16\end{cfa}
     17which matches with @const@ aliasing in other programming languages.
     18Here, the type of the enumerator is the type of the initialization constant, \eg @typeof(20u)@ for @Size@ implies @unsigned int@.
     19Auto-initialization is restricted to the case where all constants are @int@, matching with C.
     20As seen in \VRef{s:EnumeratorTyping}, this feature is just a shorthand for multiple typed-enumeration declarations.
     21
     22
     23\section{Enumerator Unscoping}
     24\label{s:EnumeratorUnscoping}
     25
     26In C, unscoped enumerators presents a \Newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names.
     27There is no mechanism in C to resolve these naming conflicts other than renaming one of the duplicates, which may be impossible.
    1328
    1429The \CFA type-system allows extensive overloading, including enumerators.
    1530Furthermore, \CFA uses the left-hand of assignment in type resolution to pinpoint the best overloaded name.
    16 Finally, qualification is provided to disambiguate any ambiguous situations.
     31Finally, qualification and casting are provided to disambiguate any ambiguous situations.
    1732\begin{cfa}
    1833enum E1 { First, Second, Third, Fourth };
    19 enum E2 { @Fourth@, @Third@, @Second@, @First@ };
     34enum E2 { @Fourth@, @Third@, @Second@, @First@ }; $\C{// same enumerator names}$
    2035E1 p() { return Third; }                                $\C{// correctly resolved duplicate names}$
    2136E2 p() { return Fourth; }
    2237void foo() {
    23         E1 e1 = First;   E2 e2 = First;
    24         e1 = Second;   e2 = Second;
    25         e1 = p();   e2 = p();                           $\C{// correctly resolved function call}$
     38        E1 e1 = First;   E2 e2 = First;         $\C{// initialization}$
     39        e1 = Second;   e2 = Second;                     $\C{// assignment}$
     40        e1 = p();   e2 = p();                           $\C{// function call}$
    2641        int i = @E1.@First + @E2.@First;        $\C{// disambiguate with qualification}$
    2742        int j = @(E1)@First + @(E2)@First;      $\C{// disambiguate with cast}$
    … …  
    2944\end{cfa}
    3045\CFA overloading allows programmers to use the most meaningful names without fear of name clashes from include files.
    31 Either the type system implicitly disambiguates or the programmer explicitly disambiguates using qualification or casting.
     46In most cases, the type system implicitly disambiguates, otherwise the programmer explicitly disambiguates using qualification or casting.
    3247
    3348
    3449\section{Enumerator Scoping}
    3550
    36 An enumeration can be scoped, so the enumerator constants are not projected into the enclosing scope, using @'!'@.
    37 \begin{cfa}
    38 enum Weekday @!@ { Mon, Tue, Wed, Thu = 10, Fri, Sat, Sun };
     51An enumeration can be scoped, using @'!'@, so the enumerator constants are not projected into the enclosing scope.
     52\begin{cfa}
     53enum Week @!@ { Mon, Tue, Wed, Thu = 10, Fri, Sat, Sun };
    3954enum RGB @!@ { Red, Green, Blue };
    4055\end{cfa}
    4156Now the enumerators \emph{must} be qualified with the associated enumeration.
    4257\begin{cfa}
    43 Weekday weekday = @Weekday@.Mon;
    44 weekday = @Weekday@.Sat;
    45 RGB rgb = RGB.Red;
    46 rgb = RGB.Blue;
     58Week week = @Week.@Mon;
     59week = @Week.@Sat;
     60RGB rgb = @RGB.@Red;
     61rgb = @RGB.@Blue;
    4762\end{cfa}
    4863It is possible to toggle back to unscoping using the \CFA @with@ clause/statement (see also \CC \lstinline[language=c++]{using enum} in Section~\ref{s:C++RelatedWork}).
    4964\begin{cfa}
    50 with ( @Weekday@, @RGB@ ) {                     $\C{// type names}$
    51          weekday = @Sun@;                               $\C{// no qualification}$
     65with ( @Week@, @RGB@ ) {                        $\C{// type names}$
     66         week = @Sun@;                                  $\C{// no qualification}$
    5267         rgb = @Green@;
    5368}
    5469\end{cfa}
    55 As in Section~\ref{s:EnumeratorNameResolution}, opening multiple unscoped enumerations can result in duplicate enumeration names, but \CFA implicit type resolution and explicit qualification/casting handles name resolution.
     70As in Section~\ref{s:EnumeratorUnscoping}, opening multiple scoped enumerations in a @with@ can result in duplicate enumeration names, but \CFA implicit type resolution and explicit qualification/casting handles ambiguities.
     71
     72
     73\section{Enumeration Pseudo-functions}
     74
     75Pseudo-functions are function-like operators that do not result in any run-time computations, \ie like @sizeof@, @alignof@, @typeof@.
     76A pseudo-function call is often substituted with information extracted from the compilation symbol-table, like storage size or alignment associated with the underlying architecture.
     77
     78The attributes of an enumerator are accessed by pseudo-functions @posE@, @valueE@, and @labelE@.
     79\begin{cfa}
     80int jane_pos = @posE@( Names.Jane );   $\C{// 2}$
     81char * jane_value = @valueE@( Names.Jane ); $\C{// "JANE"}$
     82char * jane_label = @labelE@( Names.Jane ); $\C{// "Jane"}$
     83sout | posE( Names.Jane) | labelE( Names.Jane ) | valueE( Names.Jane );
     84\end{cfa}
     85Note the ability to print all of an enumerator's properties.
     86
    5687
    5788\section{Enumerator Typing}
     89\label{s:EnumeratorTyping}
    5890
    5991\CFA extends the enumeration declaration by parameterizing with a type (like a generic type), allowing enumerators to be assigned any values from the declared type.
    6092Figure~\ref{f:EumeratorTyping} shows a series of examples illustrating that all \CFA types can be use with an enumeration and each type's constants used to set the enumerator constants.
    6193Note, the synonyms @Liz@ and @Beth@ in the last declaration.
    62 
    63 Because enumerators are constants, the enumeration type is implicitly @const@, so all the enumerator types in Figure~\ref{f:EumeratorTyping} are rewritten with @const@.
    64 A typed enumeration has an implicit (safe) conversion to its base type.
     94Because enumerators are constants, the enumeration type is implicitly @const@, so all the enumerator types in Figure~\ref{f:EumeratorTyping} are logically rewritten with @const@.
     95
     96C has an implicit type conversion from an enumerator to its base type @int@.
     97Correspondingly, \CFA has an implicit (safe) conversion from a typed enumerator to its base type.
    6598\begin{cfa}
    6699char currency = Dollar;
    … …  
    100133        struct Person { char * name; int age, height; };
    101134@***@enum( @Person@ ) friends { @Liz@ = { "ELIZABETH", 22, 170 }, @Beth@ = Liz,
    102                                                                                         Jon = { "JONATHAN", 35, 190 } };
     135                                                                        Jon = { "JONATHAN", 35, 190 } };
    103136\end{cfa}
    104137\caption{Enumerator Typing}
    … …  
    106139\end{figure}
    107140
    108 Typed enumerations deals with the \emph{harmonizing} problem between an enumeration and any companion data.
    109 The following example is from the \CFA compiler, written in \CC.
    110 \begin{cfa}
    111 enum integral_types { chr, schar, uschar, sshort, ushort, sint, usint, ..., NO_OF_ITYPES };
    112 char * integral_names[NO_OF_ITYPES] = {
    113         "char", "signed char", "unsigned char",
    114         "signed short int", "unsigned short int",
    115         "signed int", "unsigned int",
    116         ...
    117 };
    118 \end{cfa}
    119 The \emph{harmonizing} problem occurs because the enumeration declaration is in one header file and the names are declared in another translation unit.
    120 It is up to the programmer to ensure changes made in one location are harmonized with the other location (by identifying this requirement within a comment).
    121 The typed enumeration largely solves this problem by combining and managing the two data types.
     141An advantage of the typed enumerations is eliminating the \emph{harmonizing} problem between an enumeration and companion data \see{\VRef{s:Usage}}:
    122142\begin{cfa}
    123143enum( char * ) integral_types {
    … …  
    135155
    136156
    137 \section{Pure Enumerators}
    138 
    139 An empty enumerator type, @enum()@, implies the enumerators are opaque symbols without values but set properties;
    140 hence, there is no default conversion to @int@.
    141 
    142 \begin{cfa}
    143 enum() Mode { O_RDONLY, O_WRONLY, O_CREAT, O_TRUNC, O_APPEND };
    144 Mode iomode = O_RDONLY;
    145 bool b = iomode == O_RDONLY || iomode < O_APPEND; $\C{// ordering}$
    146 @***@@int i = iomode;@                                                  $\C{// disallow conversion to int}$
    147 \end{cfa}
    148 
    149 \section{Enumerator Subset}
    150 
    151 If follows from enumerator typing that the enumerator type can be another enumerator.
    152 \begin{cfa}
    153 enum( @char@ ) Currency { Dollar = '$\textdollar$', Cent = '$\textcent$', Yen = '$\textyen$', Pound = '$\textsterling$', Euro = 'E' };
    154 enum( Currency ) Europe { Euro = Currency.Euro, Pound = Currency.Pound };
    155 enum( char ) Letter { A = 'A',  B = 'B', C = 'C', ..., Z = 'Z' };
    156 enum( @Letter@ ) Greek { Alph = A, Beta = B, ..., Zeta = Z }; // intersection
    157 \end{cfa}
    158 Subset enumerations may have more or less enumerators than their typed enumeration, but the enumerator values must be from the typed enumeration.
    159 For example, @Greek@ enumerators are a subset of type @Letter@ and are type compatible with enumeration @Letter@, but @Letter@ enumerators are not type compatible with enumeration @Greek@.
    160 \begin{cfa}
    161 Letter letter = A;
    162 Greak greek = Beta;
    163 letter = Beta;                                                  $\C{// allowed, greek == B}$
    164 @greek = A;@                                                    $\C{// disallowed}$
    165 \end{cfa}
    166 
    167 
    168157\section{Enumeration Inheritance}
    169158
    … …  
    198187g( Fred );   g( Jill );
    199188h( Fred );   h( Jill );   h( Sue );
    200 j( Fred );   j( Jill );   j( Sue );   j( "WILL" );
     189 j( Fred );    j( Jill );    j( Sue );    j( "WILL" );
    201190\end{cfa}
    202191\end{tabular}
    … …  
    205194
    206195
    207 \section{Enumeration Pseudo-functions}
    208 
    209 Pseudo-functions are function-like operators that do not result in any run-time computations, \ie like @sizeof@, @offsetof@, @typeof@.
    210 Often a call to a pseudo-function is substituted with information extracted from the symbol table at compilation time, like storage size or alignment associated with the underlying architecture..
    211 
    212 The attributes of an enumerator are accessed by pseudo-functions @position@, @value@, and @label@.
    213 \begin{cfa}
    214 @***@int jane_pos = @position@( Names.Jane );   $\C{// 2}$
    215 @***@char * jane_value = @value@( Names.Jane ); $\C{// "JANE"}$
    216 @***@char * jane_label = @label@( Names.Jane ); $\C{// "Jane"}$
    217 sout | @label@( Names.Jane ) | @value@( Names.Jane );
    218 \end{cfa}
    219 Note the ability to print both enumerator label and value.
    220 
    221 
    222 \section{Enumerator Position or Value}
     196\section{Enumerator Control Structures}
    223197
    224198Enumerators can be used in multiple contexts.
    … …  
    281255
    282256
     257@if@ statement
     258
     259@switch@ statement
     260
     261looping statements
     262
     263
    283264\section{Planet Example}
    284265
    285 \VRef[Figure]{f:PlanetExample} shows an archetypal enumeration example illustrating all of the \CFA enumeration features.
     266\VRef[Figure]{f:PlanetExample} shows an archetypal enumeration example illustrating most of the \CFA enumeration features.
    286267Enumeration @Planet@ is a typed enumeration of type @MR@.
    287268Each of the planet enumerators is initialized to a specific mass/radius, @MR@, value.
    … …  
    293274struct MR { double mass, radius; };
    294275enum( MR ) Planet {
    295         //                           mass          radius
    296         MERCURY = { 3.303_E23, 2.4397_E6 },
    297         VENUS       = { 4.869_E24, 6.0518_E6 },
     276        //                      mass (kg)   radius (km)
     277        MERCURY = { 0.330_E24, 2.4397_E6 },
     278        VENUS      = { 4.869_E24, 6.0518_E6 },
    298279        EARTH       = { 5.976_E24, 6.3781_E6 },
    299         MARS         = { 6.421_E23, 3.3972_E6 },
    300         JUPITER    = { 1.898_E27, 7.1492_E7 },
    301         SATURN     = { 5.688_E26, 6.0268_E7 },
    302         URANUS    = { 8.686_E25, 2.5559_E7 },
    303         NEPTUNE  = { 1.024_E26, 2.4746_E7 },
     280        MOON        = { 7.346_E22, 1.7380_E6 }, $\C{// not a planet}$
     281        MARS         = { 0.642_E24, 3.3972_E6 },
     282        JUPITER    = { 1898._E24, 71.492_E6 },
     283        SATURN     = { 568.8_E24, 60.268_E6 },
     284        URANUS    = { 86.86_E24, 25.559_E6 },
     285        NEPTUNE  = { 102.4_E24, 24.746_E6 },
    304286};
    305 enum( double ) { G = 6.6743E-11 }; // universal gravitational constant (m3 kg-1 s-2)
     287enum( double ) { G = 6.6743E-11 }; $\C{// universal gravitational constant (m3 kg-1 s-2)}$
    306288
    307289static double surfaceGravity( Planet p ) with( p ) {
    … …  
    316298        double mass = earthWeight / surfaceGravity( EARTH );
    317299        for ( p; Planet ) {
    318                 sout | "Your weight on" | labelE(p) | "is" | surfaceWeight( p, mass );
     300                sout | "Your weight on" | labelE(p) | "is" | wd(1,1, surfaceWeight( p, mass )) | "kg";
    319301        }
    320302}
     303
     304$\$$ planet 100
     305Your weight on MERCURY is 37.7 kg
     306Your weight on VENUS is 90.5 kg
     307Your weight on EARTH is 100.0 kg
     308Your weight on MOON is 16.6 kg
     309Your weight on MARS is 37.9 kg
     310Your weight on JUPITER is 252.8 kg
     311Your weight on SATURN is 106.6 kg
     312Your weight on URANUS is 90.5 kg
     313Your weight on NEPTUNE is 113.8 kg
    321314\end{cfa}
    322315\caption{Planet Example}

  • doc/theses/jiada_liang_MMath/background.tex

    re78966e rf632117  
    11\chapter{Background}
    22
    3 \CFA is a backwards-compatible extension of the C programming language.
    4 Therefore, it must support C-style enumerations and any enumeration extensions must be intuitive to C programmers both in syntax and semantics.
     3\CFA is a backwards-compatible extension of the C programming language, therefore, it must support C-style enumerations.
     4The following covers C enumerations.
    55
    6 It is common for C programmers to ``believe'' there are three equivalent forms of named constants.
     6As discussed in \VRef{s:Aliasing}, it is common for C programmers to ``believe'' there are three equivalent forms of named constants.
    77\begin{clang}
    88#define Mon 0
    … …  
    1313\item
    1414For @#define@, the programmer has to explicitly manage the constant name and value.
    15 Furthermore, these C preprocessor macro names are outside of the C type-system, and hence cannot be overloaded, and can incorrectly change random text in a program.
     15Furthermore, these C preprocessor macro names are outside of the C type-system and can incorrectly change random text in a program.
    1616\item
    1717The same explicit management is true for the @const@ declaration, and the @const@ variable cannot appear in constant-expression locations, like @case@ labels, array dimensions,\footnote{
    … …  
    2222\end{clang}
    2323\item
    24 Only the @enum@ form is managed by the compiler, is part of the language type-system, and works in all C constant-expression locations.
     24Only the @enum@ form is managed by the compiler, is part of the language type-system, works in all C constant-expression locations, and might not occupy storage..
    2525\end{enumerate}
    2626
    2727
    2828\section{C \lstinline{const}}
     29\label{s:Cconst}
    2930
    30 As noted, C has the equivalent of Pascal typed @const@ declarations \see{\VRef{s:Pascal}}, with static and dynamic initialization.
     31C can simulate the aliasing @const@ declarations \see{\VRef{s:Aliasing}}, with static and dynamic initialization.
    3132\begin{clang}
    32 static const int one = 0 + 1;                   $\C{// static intialization}$
     33static const int one = 0 + 1;                   $\C{// static initialization}$
    3334static const void * NIL = NULL;
    3435static const double PI = 3.14159;
    … …  
    3839                                        Sat = Fri + 1, Sun = Sat + 1;
    3940void foo() {
    40         const int r = random();                         $\C{// dynamic intialization}$
    41         int sa[Sun];                                            $\C{// VLA, local scope only}$
     41        const int r = random() % 100;           $\C{// dynamic intialization}$
     42        int va[r];                                                      $\C{// VLA, auto scope only}$
    4243}
    4344\end{clang}
    4445Statically initialized identifiers may appear in any constant-expression context, \eg @case@.
    45 Dynamically initialized identifiers may appear as array dimensions in @g++@, which allows variable-sized arrays.
     46Dynamically initialized identifiers may appear as array dimensions in @g++@, which allows variable-sized arrays on the stack.
     47Again, this form of aliasing to primary constant is not an enumeration.
    4648
    4749
    … …  
    6365\end{clang}
    6466The terms \emph{enumeration} and \emph{enumerator} used in this work \see{\VRef{s:Terminology}} come from the grammar.
    65 The C enumeration semantics is discussed using examples.
     67The C enumeration semantics are discussed using examples.
    6668
    67 An unnamed enumeration is used to provide secondary renaming, like a @const@ declaration in other languages.
     69
     70\subsection{Type Name}
     71\label{s:TypeName}
     72
     73An \emph{unnamed} enumeration is used to provide aliasing \see{\VRef{s:Aliasing}} exactly like a @const@ declaration in other languages.
     74However, it is restricted to integral values.
    6875\begin{clang}
    69 enum { Size = 20, Pi = 3.14159 };   // unnamed enumeration $\(\Rightarrow\)$ no ordering
     76enum { Size = 20, Max = 10, MaxPlus10 = Max + 10, Max10Plus1, Fred = -7 };
    7077\end{clang}
    71 This declaration form is not an enumeration even though it is declared using an @enum@ because it has none of the following enumeration properties.
     78Here, the aliased constants are: 20, 10, 20, 21, and -7.
     79Direct initialization is by a compile-time expression generating a constant value.
     80An enumerator without initialization is \Newterm{auto-initialized}: from left to right, starting at zero or the next explicitly initialized constant, incrementing by @1@.
     81Because multiple independent enumerators can be combined, enumerators with the same values can occur.
     82The enumerators are rvalues, so assignment is disallowed.
     83Finally, enumerators are \Newterm{unscoped}, \ie enumerators declared inside of an @enum@ are visible (projected) into the enclosing scope of the @enum@ type.
     84For unnamed enumeration this semantic is required because there is no type name for scoped qualification.
    7285
    73 A \emph{named} enumeration type is an actual enumeration.
     86As noted, this kind of aliasing declaration is not an enumeration, even though it is declared using an @enum@ in C.
     87While the semantics is misleading, this enumeration form matches with aggregate types:
     88\begin{cfa}
     89typedef struct /* unnamed */  { ... } S;
     90struct /* unnamed */  { ... } x, y, z;                  $\C{// questionable}$
     91struct S {
     92        union /* unnamed */ {                                           $\C{// unscoped fields}$
     93                int i;  double d ;  char ch;
     94        };
     95};
     96\end{cfa}
     97Hence, C programmers would expect this enumeration form to exist in harmony with the aggregate form.
     98
     99A \emph{named} enumeration is an enumeration:
    74100\begin{clang}
    75 enum Weekday { Mon, Tue, Wed, Thu@ = 10@, Fri, Sat, Sun, };
     101enum @Week@ { Mon, Tue, Wed, Thu@ = 10@, Fri, Sat, Sun };
    76102\end{clang}
    77 Enumerators without an explicitly designated constant value are \Newterm{auto-initialized} by the compiler: from left to right, starting at zero or the next explicitly initialized constant, incrementing by @1@.
     103and adopts the same semantics with respect to direct and auto intialization.
    78104For example, @Mon@ to @Wed@ are implicitly assigned with constants @0@--@2@, @Thu@ is explicitly set to constant @10@, and @Fri@ to @Sun@ are implicitly assigned with constants @11@--@13@.
    79 Initialization may occur in any order.
     105As well, initialization may occur in any order.
    80106\begin{clang}
    81 enum Weekday { Thu@ = 10@, Fri, Sat, Sun, Mon@ = 0@, Tue, Wed };
     107enum Week {
     108        Thu@ = 10@, Fri, Sat, Sun,
     109        Mon@ = 0@, Tue, Wed@,@ }; // terminating comma
    82110\end{clang}
    83 Note, the comma in the enumerator list can be a terminator or a separator, allowing the list to end with a dangling comma.
     111Note, the comma in the enumerator list can be a terminator or a separator, allowing the list to end with a dangling comma.\footnote{
     112A terminating comma appears in other C syntax, \eg the initializer list.}
     113This feature allow enumerator lines to be interchanged without moving a comma.
     114Named enumerators are also unscoped.
     115
     116
     117\subsection{Implementation}
     118
     119In theory, a C enumeration \emph{variable} is an implementation-defined integral type large enough to hold all enumerator values.
     120In practice, C uses @int@ as the underlying type for enumeration variables, because of the restriction to integral constants, which have type @int@ (unless qualified with a size suffix).
     121
     122
     123\subsection{Usage}
     124\label{s:Usage}
     125
     126C proves an implicit \emph{bidirectional} conversion between an enumeration and its integral type.
    84127\begin{clang}
    85 enum Weekday {
    86         Thu = 10, Fri, Sat, Sun,
    87         Mon = 0, Tue, Wed@,@ // terminating comma
     128enum Week week = Mon;                           $\C{// week == 0}$
     129week = Fri;                                                     $\C{// week == 11}$
     130int i = Sun;                                            $\C{// implicit conversion to int, i == 13}$
     131@week = 10000;@                                         $\C{// UNDEFINED! implicit conversion to Week}$
     132\end{clang}
     133While converting an enumerator to underlying type is useful, the implicit conversion from the base type to an enumeration type is a common source of error.
     134
     135Enumerators can appear in @switch@ and looping statements.
     136\begin{cfa}
     137enum Week { Mon, Tue, Wed, Thu, Fri, Sat, Sun };
     138switch ( week ) {
     139        case Mon: case Tue: case Wed: case Thu: case Fri:
     140                printf( "weekday\n" );
     141        case Sat: case Sun:
     142                printf( "weekend\n" );
     143}
     144for ( enum Week day = Mon; day <= Sun; day += 1 ) {
     145        printf( "day %d\n", day ); // 0-6
     146}
     147\end{cfa}
     148For iterating, the enumerator values \emph{must} have a consecutive ordering with a fixed step between values.
     149Note, it is the bidirectional conversion that allows incrementing @day@: @day@ is converted to @int@, integer @1@ is added, and the result is converted back to @Week@ for the assignment to @day@.
     150For safety, \CC does not support the bidirectional conversion, and hence, an unsafe cast is necessary to increment @day@: @day = (Week)(day + 1)@.
     151
     152There is a C idiom to automatically know the number of enumerators in an enumeration.
     153\begin{cfa}
     154enum E { A, B, C, D, @N@ };  // N == 4
     155for ( enum E e = A; e < @N@; e += 1 ) ...
     156\end{cfa}
     157Here, the auto-incrementing counts the number of enumerators and puts the total into the last enumerator @N@.
     158@N@ is often used as the dimension for an array assocated with the enumeration.
     159\begin{cfa}
     160E array[@N@];
     161for ( enum E e = A; e < N; e += 1 ) {
     162        array[e] = e;
     163}
     164\end{cfa}
     165However, for typed enumerations, \see{\VRef{f:EumeratorTyping}}, this idiom fails.
     166
     167This idiom leads to another C idiom using an enumeration with matching companion information.
     168For example, an enumeration is linked with a companion array of printable strings.
     169\begin{cfa}
     170enum Integral_Type { chr, schar, uschar, sshort, ushort, sint, usint, ..., NO_OF_ITYPES };
     171char * Integral_Name[@NO_OF_ITYPES@] = {
     172        "char", "signed char", "unsigned char",
     173        "signed short int", "unsigned short int",
     174        "signed int", "unsigned int", ...
    88175};
    89 \end{clang}
    90 This feature allow enumerator lines to be interchanged without moving a comma.\footnote{
    91 A terminating comma appears in other C syntax, \eg the initializer list.}
    92 Finally, C enumerators are \Newterm{unscoped}, \ie enumerators declared inside of an @enum@ are visible (projected) into the enclosing scope of the @enum@ type.
     176enum Integral_Type integral_type = ...
     177printf( "%s\n", Integral_Name[@integral_type@] ); // human readable type name
     178\end{cfa}
     179However, the companion idiom results in the \emph{harmonizing} problem because an update to the enumeration @Integral_Type@ often requires a corresponding update to the companion array \snake{Integral_Name}.
     180The need to harmonize is at best indicated by a comment before the enumeration.
     181This issue is exacerbated if enumeration and companion array are in different translation units.
    93182
    94 In theory, a C enumeration \emph{variable} is an implementation-defined integral type large enough to hold all enumerated values.
    95 In practice, since integral constants are used, which have type @int@ (unless qualified with a size suffix), C uses @int@ as the underlying type for enumeration variables.
    96 Finally, there is an implicit bidirectional conversion between an enumeration and its integral type.
    97 \begin{clang}
    98 {
    99         enum Weekday { /* as above */ };        $\C{// enumerators implicitly projected into local scope}$
    100         Weekday weekday = Mon;                          $\C{// weekday == 0}$
    101         weekday = Fri;                                          $\C{// weekday == 11}$
    102         int i = Sun;                                            $\C{// implicit conversion to int, i == 13}$
    103         weekday = 10000;                                        $\C{// UNDEFINED! implicit conversion to Weekday}$
    104 }
    105 int j = Wed;                                                    $\C{// ERROR! Wed is not declared in this scope}$
    106 \end{clang}
    107 The implicit conversion from @int@ to an enumeration type is an unnecessary source of error.
     183\bigskip
     184While C provides a true enumeration, it is restricted, has unsafe semantics, and does provide enumeration features in other programming languages.

  • doc/theses/jiada_liang_MMath/intro.tex

    re78966e rf632117  
    9999
    100100\subsection{Aliasing}
     101\label{s:Aliasing}
    101102
    102103Some languages provide simple secondary aliasing (renaming), \eg:

  • doc/theses/jiada_liang_MMath/relatedwork.tex

    re78966e rf632117  
    1818\end{comment}
    1919
    20 Enumeration types exist in many popular programming languages, both past and present, \eg Pascal~\cite{Pascal}, Ada~\cite{Ada}, \Csharp~\cite{Csharp}, OCaml~\cite{OCaml} \CC, Go~\cite{Go}, Java~\cite{Java}, Modula-3~\cite{Modula-3}, Rust~\cite{Rust}, Swift~\cite{Swift}, Python~\cite{Python}.
     20Enumeration-like features exist in many popular programming languages, both past and present, \eg Pascal~\cite{Pascal}, Ada~\cite{Ada}, \Csharp~\cite{Csharp}, OCaml~\cite{OCaml} \CC, Go~\cite{Go}, Haskell~\cite{Haskell}, Java~\cite{Java}, Modula-3~\cite{Modula-3}, Rust~\cite{Rust}, Swift~\cite{Swift}, Python~\cite{Python}.
    2121Among theses languages, there are a large set of overlapping features, but each language has its own unique extensions and restrictions.
    2222
    … …  
    2424\label{s:Pascal}
    2525
    26 Classic Pascal has the \lstinline[language=pascal]{const} declaration binding a name to a constant literal/expression.
     26Classic Pascal has the \lstinline[language=Pascal]{const} aliasing declaration binding a name to a constant literal/expression.
    2727\begin{pascal}
    2828const one = 0 + 1;   Vowels = set of (A,E,I,O,U);   NULL = NIL;
    2929                 PI = 3.14159;   Plus = '+';   Fred = 'Fred';
    3030\end{pascal}
    31 This mechanism is not an enumeration because there is no specific type (pseudo enumeration).
     31As stated, this mechanism is not an enumeration because there is no specific type (pseudo enumeration).
    3232Hence, there is no notion of a (possibly ordered) set, modulo the \lstinline[language=pascal]{set of} type.
    3333The type of each constant name (enumerator) is inferred from the constant-expression type.
    … …  
    139139Ops : array( 0..3 ) of Operator;
    140140Ops := @"+-*/"@;            -- string assignment to array elements
    141 Ops := @"+-" & "*/"@;   -- string concatenation and assignment
     141Ops := "+-" @&@ "*/";   -- string concatenation and assignment
    142142\end{ada}
    143143Ada's @Character@ type is defined as a character enumeration across all Latin-1 characters.
    … …  
    215215\label{s:C++RelatedWork}
    216216
    217 \CC has the equivalent of Pascal typed @const@ declarations \see{\VRef{s:Pascal}}, with static and dynamic initialization.
     217\CC enumeration is largely backwards compatible with C, so it inherited C's enumerations with some modifications and additions.
     218
     219\CC has aliasing using @const@ declarations, like C \see{\VRef{s:Cconst}}, with type inferencing, plus static/dynamic initialization.
     220(Note, a \CC @constexpr@ declaration is the same @const@ with the restriction that the initialization is a compile-time expression.)
    218221\begin{c++}
    219 const auto one = 0 + 1;                                 $\C{// static initialization}$
    220 const auto NULL = nullptr;
    221 const auto PI = 3.14159;
    222 const auto Plus = '+';
    223 const auto Fred = "Fred";
    224 const auto Mon = 0, Tue = Mon + 1, Wed = Tue + 1, Thu = Wed + 1, Fri = Thu + 1,
     222const @auto@ one = 0 + 1;                               $\C{// static initialization}$
     223const @auto@ NIL = nullptr;
     224const @auto@ PI = 3.14159;
     225const @auto@ Plus = '+';
     226const @auto@ Fred = "Fred";
     227const @auto@ Mon = 0, Tue = Mon + 1, Wed = Tue + 1, Thu = Wed + 1, Fri = Thu + 1,
    225228                                Sat = Fri + 1, Sun = Sat + 1;
    226 int sa[Sun];
    227 const auto r = random();                                $\C{// dynamic initialization}$
    228 int da[r];                                                              $\C{// VLA}$
     229void foo() {
     230        const @auto@ r = random();                      $\C{// dynamic initialization}$
     231        int va[r];                                                      $\C{// VLA, auto scope only}$
     232}
    229233\end{c++}
    230234Statically initialized identifiers may appear in any constant-expression context, \eg @case@.
    231 Dynamically intialized identifiers may appear as array dimensions in @g++@, which allows variable-sized arrays.
    232 Interestingly, global \CC @const@ declarations are implicitly marked @static@ (@r@ rather than @R@).
     235Dynamically initialized identifiers may appear as array dimensions in @g++@, which allows variable-sized arrays.
     236Interestingly, global \CC @const@ declarations are implicitly marked @static@ (@r@, read-only local, rather than @R@, read-only external)
    233237\begin{c++}
    234238$\$$ nm test.o
    2352390000000000000018 @r@ Mon
    236240\end{c++}
    237 
    238 \CC enumeration is largely backwards compatible with C, so it inherited C's enumerations.
    239 However, the following non-backwards compatible changes are made.
    240 
     241whereas C @const@ declarations without @static@ are marked @R@.
     242
     243The following non-backwards compatible changes are made \see{\cite[\S~7.2]{ANSI98:C++}}.
    241244\begin{cquote}
    242 7.2 Change: \CC objects of enumeration type can only be assigned values of the same enumeration type.
     245Change: \CC objects of enumeration type can only be assigned values of the same enumeration type.
    243246In C, objects of enumeration type can be assigned values of any integral type. \\
    244247Example:
    … …  
    254257
    255258\begin{cquote}
    256 7.2 Change: In \CC, the type of an enumerator is its enumeration.
     259Change: In \CC, the type of an enumerator is its enumeration.
    257260In C, the type of an enumerator is @int@. \\
    258261Example:
    … …  
    269272Taking the size of an enumerator is not a common C coding practice.
    270273\end{cquote}
    271 
    272274Hence, the values in a \CC enumeration can only be its enumerators (without a cast).
    273275While the storage size of an enumerator is up to the compiler, there is still an implicit cast to @int@.
Note: See TracChangeset for help on using the changeset viewer.