Index: doc/theses/jiada_liang_MMath/CFAenum.tex =================================================================== --- doc/theses/jiada_liang_MMath/CFAenum.tex (revision 314c9d8852a35c6736a8f3ae5920e3ca35122ba7) +++ doc/theses/jiada_liang_MMath/CFAenum.tex (revision f6321173aa4ceab077c8b556511650b082af253e) @@ -4,24 +4,39 @@ \CFA supports C enumeration using the same syntax and semantics for backwards compatibility. \CFA also extends C-Style enumeration by adding a number of new features that bring enumerations inline with other modern programming languages. - - -\section{Enumerator Name Resolution} -\label{s:EnumeratorNameResolution} - -In C, unscoping of enumerators presents a \Newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names. -There is no mechanism in C to resolve these naming conflicts other than renaming of one of the duplicates, which may be impossible. +Any enumeration extensions must be intuitive to C programmers both in syntax and semantics. +The following sections detail all of my new contributions to enumerations in \CFA. + + +\section{Aliasing} + +C already provides @const@-style aliasing using the unnamed enumerator \see{\VRef{s:TypeName}}, even if the name @enum@ is misleading (@const@ would be better). +Given the existence of this form, it is straightforward to extend it with types other than integers. +\begin{cfa} +enum E { Size = 20u, PI = 3.14159L, Jack = L"John" }; +\end{cfa} +which matches with @const@ aliasing in other programming languages. +Here, the type of the enumerator is the type of the initialization constant, \eg @typeof(20u)@ for @Size@ implies @unsigned int@. +Auto-initialization is restricted to the case where all constants are @int@, matching with C. +As seen in \VRef{s:EnumeratorTyping}, this feature is just a shorthand for multiple typed-enumeration declarations. + + +\section{Enumerator Unscoping} +\label{s:EnumeratorUnscoping} + +In C, unscoped enumerators presents a \Newterm{naming problem} when multiple enumeration types appear in the same scope with duplicate enumerator names. +There is no mechanism in C to resolve these naming conflicts other than renaming one of the duplicates, which may be impossible. The \CFA type-system allows extensive overloading, including enumerators. Furthermore, \CFA uses the left-hand of assignment in type resolution to pinpoint the best overloaded name. -Finally, qualification is provided to disambiguate any ambiguous situations. +Finally, qualification and casting are provided to disambiguate any ambiguous situations. \begin{cfa} enum E1 { First, Second, Third, Fourth }; -enum E2 { @Fourth@, @Third@, @Second@, @First@ }; +enum E2 { @Fourth@, @Third@, @Second@, @First@ }; $\C{// same enumerator names}$ E1 p() { return Third; } $\C{// correctly resolved duplicate names}$ E2 p() { return Fourth; } void foo() { - E1 e1 = First; E2 e2 = First; - e1 = Second; e2 = Second; - e1 = p(); e2 = p(); $\C{// correctly resolved function call}$ + E1 e1 = First; E2 e2 = First; $\C{// initialization}$ + e1 = Second; e2 = Second; $\C{// assignment}$ + e1 = p(); e2 = p(); $\C{// function call}$ int i = @E1.@First + @E2.@First; $\C{// disambiguate with qualification}$ int j = @(E1)@First + @(E2)@First; $\C{// disambiguate with cast}$ @@ -29,38 +44,56 @@ \end{cfa} \CFA overloading allows programmers to use the most meaningful names without fear of name clashes from include files. -Either the type system implicitly disambiguates or the programmer explicitly disambiguates using qualification or casting. +In most cases, the type system implicitly disambiguates, otherwise the programmer explicitly disambiguates using qualification or casting. \section{Enumerator Scoping} -An enumeration can be scoped, so the enumerator constants are not projected into the enclosing scope, using @'!'@. -\begin{cfa} -enum Weekday @!@ { Mon, Tue, Wed, Thu = 10, Fri, Sat, Sun }; +An enumeration can be scoped, using @'!'@, so the enumerator constants are not projected into the enclosing scope. +\begin{cfa} +enum Week @!@ { Mon, Tue, Wed, Thu = 10, Fri, Sat, Sun }; enum RGB @!@ { Red, Green, Blue }; \end{cfa} Now the enumerators \emph{must} be qualified with the associated enumeration. \begin{cfa} -Weekday weekday = @Weekday@.Mon; -weekday = @Weekday@.Sat; -RGB rgb = RGB.Red; -rgb = RGB.Blue; +Week week = @Week.@Mon; +week = @Week.@Sat; +RGB rgb = @RGB.@Red; +rgb = @RGB.@Blue; \end{cfa} It 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}). \begin{cfa} -with ( @Weekday@, @RGB@ ) { $\C{// type names}$ - weekday = @Sun@; $\C{// no qualification}$ +with ( @Week@, @RGB@ ) { $\C{// type names}$ + week = @Sun@; $\C{// no qualification}$ rgb = @Green@; } \end{cfa} -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. +As 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. + + +\section{Enumeration Pseudo-functions} + +Pseudo-functions are function-like operators that do not result in any run-time computations, \ie like @sizeof@, @alignof@, @typeof@. +A pseudo-function call is often substituted with information extracted from the compilation symbol-table, like storage size or alignment associated with the underlying architecture. + +The attributes of an enumerator are accessed by pseudo-functions @posE@, @valueE@, and @labelE@. +\begin{cfa} +int jane_pos = @posE@( Names.Jane ); $\C{// 2}$ +char * jane_value = @valueE@( Names.Jane ); $\C{// "JANE"}$ +char * jane_label = @labelE@( Names.Jane ); $\C{// "Jane"}$ +sout | posE( Names.Jane) | labelE( Names.Jane ) | valueE( Names.Jane ); +\end{cfa} +Note the ability to print all of an enumerator's properties. + \section{Enumerator Typing} +\label{s:EnumeratorTyping} \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. Figure~\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. Note, the synonyms @Liz@ and @Beth@ in the last declaration. - -Because enumerators are constants, the enumeration type is implicitly @const@, so all the enumerator types in Figure~\ref{f:EumeratorTyping} are rewritten with @const@. -A typed enumeration has an implicit (safe) conversion to its base type. +Because enumerators are constants, the enumeration type is implicitly @const@, so all the enumerator types in Figure~\ref{f:EumeratorTyping} are logically rewritten with @const@. + +C has an implicit type conversion from an enumerator to its base type @int@. +Correspondingly, \CFA has an implicit (safe) conversion from a typed enumerator to its base type. \begin{cfa} char currency = Dollar; @@ -100,5 +133,5 @@ struct Person { char * name; int age, height; }; @***@enum( @Person@ ) friends { @Liz@ = { "ELIZABETH", 22, 170 }, @Beth@ = Liz, - Jon = { "JONATHAN", 35, 190 } }; + Jon = { "JONATHAN", 35, 190 } }; \end{cfa} \caption{Enumerator Typing} @@ -106,18 +139,5 @@ \end{figure} -Typed enumerations deals with the \emph{harmonizing} problem between an enumeration and any companion data. -The following example is from the \CFA compiler, written in \CC. -\begin{cfa} -enum integral_types { chr, schar, uschar, sshort, ushort, sint, usint, ..., NO_OF_ITYPES }; -char * integral_names[NO_OF_ITYPES] = { - "char", "signed char", "unsigned char", - "signed short int", "unsigned short int", - "signed int", "unsigned int", - ... -}; -\end{cfa} -The \emph{harmonizing} problem occurs because the enumeration declaration is in one header file and the names are declared in another translation unit. -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). -The typed enumeration largely solves this problem by combining and managing the two data types. +An advantage of the typed enumerations is eliminating the \emph{harmonizing} problem between an enumeration and companion data \see{\VRef{s:Usage}}: \begin{cfa} enum( char * ) integral_types { @@ -135,35 +155,4 @@ -\section{Pure Enumerators} - -An empty enumerator type, @enum()@, implies the enumerators are opaque symbols without values but set properties; -hence, there is no default conversion to @int@. - -\begin{cfa} -enum() Mode { O_RDONLY, O_WRONLY, O_CREAT, O_TRUNC, O_APPEND }; -Mode iomode = O_RDONLY; -bool b = iomode == O_RDONLY || iomode < O_APPEND; $\C{// ordering}$ -@***@@int i = iomode;@ $\C{// disallow conversion to int}$ -\end{cfa} - -\section{Enumerator Subset} - -If follows from enumerator typing that the enumerator type can be another enumerator. -\begin{cfa} -enum( @char@ ) Currency { Dollar = '$\textdollar$', Cent = '$\textcent$', Yen = '$\textyen$', Pound = '$\textsterling$', Euro = 'E' }; -enum( Currency ) Europe { Euro = Currency.Euro, Pound = Currency.Pound }; -enum( char ) Letter { A = 'A', B = 'B', C = 'C', ..., Z = 'Z' }; -enum( @Letter@ ) Greek { Alph = A, Beta = B, ..., Zeta = Z }; // intersection -\end{cfa} -Subset enumerations may have more or less enumerators than their typed enumeration, but the enumerator values must be from the typed enumeration. -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@. -\begin{cfa} -Letter letter = A; -Greak greek = Beta; -letter = Beta; $\C{// allowed, greek == B}$ -@greek = A;@ $\C{// disallowed}$ -\end{cfa} - - \section{Enumeration Inheritance} @@ -198,5 +187,5 @@ g( Fred ); g( Jill ); h( Fred ); h( Jill ); h( Sue ); -j( Fred ); j( Jill ); j( Sue ); j( "WILL" ); + j( Fred ); j( Jill ); j( Sue ); j( "WILL" ); \end{cfa} \end{tabular} @@ -205,20 +194,5 @@ -\section{Enumeration Pseudo-functions} - -Pseudo-functions are function-like operators that do not result in any run-time computations, \ie like @sizeof@, @offsetof@, @typeof@. -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.. - -The attributes of an enumerator are accessed by pseudo-functions @position@, @value@, and @label@. -\begin{cfa} -@***@int jane_pos = @position@( Names.Jane ); $\C{// 2}$ -@***@char * jane_value = @value@( Names.Jane ); $\C{// "JANE"}$ -@***@char * jane_label = @label@( Names.Jane ); $\C{// "Jane"}$ -sout | @label@( Names.Jane ) | @value@( Names.Jane ); -\end{cfa} -Note the ability to print both enumerator label and value. - - -\section{Enumerator Position or Value} +\section{Enumerator Control Structures} Enumerators can be used in multiple contexts. @@ -281,7 +255,14 @@ +@if@ statement + +@switch@ statement + +looping statements + + \section{Planet Example} -\VRef[Figure]{f:PlanetExample} shows an archetypal enumeration example illustrating all of the \CFA enumeration features. +\VRef[Figure]{f:PlanetExample} shows an archetypal enumeration example illustrating most of the \CFA enumeration features. Enumeration @Planet@ is a typed enumeration of type @MR@. Each of the planet enumerators is initialized to a specific mass/radius, @MR@, value. @@ -293,15 +274,16 @@ struct MR { double mass, radius; }; enum( MR ) Planet { - // mass radius - MERCURY = { 3.303_E23, 2.4397_E6 }, - VENUS = { 4.869_E24, 6.0518_E6 }, + // mass (kg) radius (km) + MERCURY = { 0.330_E24, 2.4397_E6 }, + VENUS = { 4.869_E24, 6.0518_E6 }, EARTH = { 5.976_E24, 6.3781_E6 }, - MARS = { 6.421_E23, 3.3972_E6 }, - JUPITER = { 1.898_E27, 7.1492_E7 }, - SATURN = { 5.688_E26, 6.0268_E7 }, - URANUS = { 8.686_E25, 2.5559_E7 }, - NEPTUNE = { 1.024_E26, 2.4746_E7 }, + MOON = { 7.346_E22, 1.7380_E6 }, $\C{// not a planet}$ + MARS = { 0.642_E24, 3.3972_E6 }, + JUPITER = { 1898._E24, 71.492_E6 }, + SATURN = { 568.8_E24, 60.268_E6 }, + URANUS = { 86.86_E24, 25.559_E6 }, + NEPTUNE = { 102.4_E24, 24.746_E6 }, }; -enum( double ) { G = 6.6743E-11 }; // universal gravitational constant (m3 kg-1 s-2) +enum( double ) { G = 6.6743E-11 }; $\C{// universal gravitational constant (m3 kg-1 s-2)}$ static double surfaceGravity( Planet p ) with( p ) { @@ -316,7 +298,18 @@ double mass = earthWeight / surfaceGravity( EARTH ); for ( p; Planet ) { - sout | "Your weight on" | labelE(p) | "is" | surfaceWeight( p, mass ); + sout | "Your weight on" | labelE(p) | "is" | wd(1,1, surfaceWeight( p, mass )) | "kg"; } } + +$\$$ planet 100 +Your weight on MERCURY is 37.7 kg +Your weight on VENUS is 90.5 kg +Your weight on EARTH is 100.0 kg +Your weight on MOON is 16.6 kg +Your weight on MARS is 37.9 kg +Your weight on JUPITER is 252.8 kg +Your weight on SATURN is 106.6 kg +Your weight on URANUS is 90.5 kg +Your weight on NEPTUNE is 113.8 kg \end{cfa} \caption{Planet Example} Index: doc/theses/jiada_liang_MMath/background.tex =================================================================== --- doc/theses/jiada_liang_MMath/background.tex (revision 314c9d8852a35c6736a8f3ae5920e3ca35122ba7) +++ doc/theses/jiada_liang_MMath/background.tex (revision f6321173aa4ceab077c8b556511650b082af253e) @@ -1,8 +1,8 @@ \chapter{Background} -\CFA is a backwards-compatible extension of the C programming language. -Therefore, it must support C-style enumerations and any enumeration extensions must be intuitive to C programmers both in syntax and semantics. +\CFA is a backwards-compatible extension of the C programming language, therefore, it must support C-style enumerations. +The following covers C enumerations. -It is common for C programmers to ``believe'' there are three equivalent forms of named constants. +As discussed in \VRef{s:Aliasing}, it is common for C programmers to ``believe'' there are three equivalent forms of named constants. \begin{clang} #define Mon 0 @@ -13,5 +13,5 @@ \item For @#define@, the programmer has to explicitly manage the constant name and value. -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. +Furthermore, these C preprocessor macro names are outside of the C type-system and can incorrectly change random text in a program. \item The 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{ @@ -22,13 +22,14 @@ \end{clang} \item -Only the @enum@ form is managed by the compiler, is part of the language type-system, and works in all C constant-expression locations. +Only 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.. \end{enumerate} \section{C \lstinline{const}} +\label{s:Cconst} -As noted, C has the equivalent of Pascal typed @const@ declarations \see{\VRef{s:Pascal}}, with static and dynamic initialization. +C can simulate the aliasing @const@ declarations \see{\VRef{s:Aliasing}}, with static and dynamic initialization. \begin{clang} -static const int one = 0 + 1; $\C{// static intialization}$ +static const int one = 0 + 1; $\C{// static initialization}$ static const void * NIL = NULL; static const double PI = 3.14159; @@ -38,10 +39,11 @@ Sat = Fri + 1, Sun = Sat + 1; void foo() { - const int r = random(); $\C{// dynamic intialization}$ - int sa[Sun]; $\C{// VLA, local scope only}$ + const int r = random() % 100; $\C{// dynamic intialization}$ + int va[r]; $\C{// VLA, auto scope only}$ } \end{clang} Statically initialized identifiers may appear in any constant-expression context, \eg @case@. -Dynamically initialized identifiers may appear as array dimensions in @g++@, which allows variable-sized arrays. +Dynamically initialized identifiers may appear as array dimensions in @g++@, which allows variable-sized arrays on the stack. +Again, this form of aliasing to primary constant is not an enumeration. @@ -63,45 +65,120 @@ \end{clang} The terms \emph{enumeration} and \emph{enumerator} used in this work \see{\VRef{s:Terminology}} come from the grammar. -The C enumeration semantics is discussed using examples. +The C enumeration semantics are discussed using examples. -An unnamed enumeration is used to provide secondary renaming, like a @const@ declaration in other languages. + +\subsection{Type Name} +\label{s:TypeName} + +An \emph{unnamed} enumeration is used to provide aliasing \see{\VRef{s:Aliasing}} exactly like a @const@ declaration in other languages. +However, it is restricted to integral values. \begin{clang} -enum { Size = 20, Pi = 3.14159 }; // unnamed enumeration $\(\Rightarrow\)$ no ordering +enum { Size = 20, Max = 10, MaxPlus10 = Max + 10, Max10Plus1, Fred = -7 }; \end{clang} -This declaration form is not an enumeration even though it is declared using an @enum@ because it has none of the following enumeration properties. +Here, the aliased constants are: 20, 10, 20, 21, and -7. +Direct initialization is by a compile-time expression generating a constant value. +An enumerator without initialization is \Newterm{auto-initialized}: from left to right, starting at zero or the next explicitly initialized constant, incrementing by @1@. +Because multiple independent enumerators can be combined, enumerators with the same values can occur. +The enumerators are rvalues, so assignment is disallowed. +Finally, enumerators are \Newterm{unscoped}, \ie enumerators declared inside of an @enum@ are visible (projected) into the enclosing scope of the @enum@ type. +For unnamed enumeration this semantic is required because there is no type name for scoped qualification. -A \emph{named} enumeration type is an actual enumeration. +As noted, this kind of aliasing declaration is not an enumeration, even though it is declared using an @enum@ in C. +While the semantics is misleading, this enumeration form matches with aggregate types: +\begin{cfa} +typedef struct /* unnamed */ { ... } S; +struct /* unnamed */ { ... } x, y, z; $\C{// questionable}$ +struct S { + union /* unnamed */ { $\C{// unscoped fields}$ + int i; double d ; char ch; + }; +}; +\end{cfa} +Hence, C programmers would expect this enumeration form to exist in harmony with the aggregate form. + +A \emph{named} enumeration is an enumeration: \begin{clang} -enum Weekday { Mon, Tue, Wed, Thu@ = 10@, Fri, Sat, Sun, }; +enum @Week@ { Mon, Tue, Wed, Thu@ = 10@, Fri, Sat, Sun }; \end{clang} -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@. +and adopts the same semantics with respect to direct and auto intialization. For 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@. -Initialization may occur in any order. +As well, initialization may occur in any order. \begin{clang} -enum Weekday { Thu@ = 10@, Fri, Sat, Sun, Mon@ = 0@, Tue, Wed }; +enum Week { + Thu@ = 10@, Fri, Sat, Sun, + Mon@ = 0@, Tue, Wed@,@ }; // terminating comma \end{clang} -Note, the comma in the enumerator list can be a terminator or a separator, allowing the list to end with a dangling comma. +Note, the comma in the enumerator list can be a terminator or a separator, allowing the list to end with a dangling comma.\footnote{ +A terminating comma appears in other C syntax, \eg the initializer list.} +This feature allow enumerator lines to be interchanged without moving a comma. +Named enumerators are also unscoped. + + +\subsection{Implementation} + +In theory, a C enumeration \emph{variable} is an implementation-defined integral type large enough to hold all enumerator values. +In 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). + + +\subsection{Usage} +\label{s:Usage} + +C proves an implicit \emph{bidirectional} conversion between an enumeration and its integral type. \begin{clang} -enum Weekday { - Thu = 10, Fri, Sat, Sun, - Mon = 0, Tue, Wed@,@ // terminating comma +enum Week week = Mon; $\C{// week == 0}$ +week = Fri; $\C{// week == 11}$ +int i = Sun; $\C{// implicit conversion to int, i == 13}$ +@week = 10000;@ $\C{// UNDEFINED! implicit conversion to Week}$ +\end{clang} +While 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. + +Enumerators can appear in @switch@ and looping statements. +\begin{cfa} +enum Week { Mon, Tue, Wed, Thu, Fri, Sat, Sun }; +switch ( week ) { + case Mon: case Tue: case Wed: case Thu: case Fri: + printf( "weekday\n" ); + case Sat: case Sun: + printf( "weekend\n" ); +} +for ( enum Week day = Mon; day <= Sun; day += 1 ) { + printf( "day %d\n", day ); // 0-6 +} +\end{cfa} +For iterating, the enumerator values \emph{must} have a consecutive ordering with a fixed step between values. +Note, 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@. +For safety, \CC does not support the bidirectional conversion, and hence, an unsafe cast is necessary to increment @day@: @day = (Week)(day + 1)@. + +There is a C idiom to automatically know the number of enumerators in an enumeration. +\begin{cfa} +enum E { A, B, C, D, @N@ }; // N == 4 +for ( enum E e = A; e < @N@; e += 1 ) ... +\end{cfa} +Here, the auto-incrementing counts the number of enumerators and puts the total into the last enumerator @N@. +@N@ is often used as the dimension for an array assocated with the enumeration. +\begin{cfa} +E array[@N@]; +for ( enum E e = A; e < N; e += 1 ) { + array[e] = e; +} +\end{cfa} +However, for typed enumerations, \see{\VRef{f:EumeratorTyping}}, this idiom fails. + +This idiom leads to another C idiom using an enumeration with matching companion information. +For example, an enumeration is linked with a companion array of printable strings. +\begin{cfa} +enum Integral_Type { chr, schar, uschar, sshort, ushort, sint, usint, ..., NO_OF_ITYPES }; +char * Integral_Name[@NO_OF_ITYPES@] = { + "char", "signed char", "unsigned char", + "signed short int", "unsigned short int", + "signed int", "unsigned int", ... }; -\end{clang} -This feature allow enumerator lines to be interchanged without moving a comma.\footnote{ -A terminating comma appears in other C syntax, \eg the initializer list.} -Finally, C enumerators are \Newterm{unscoped}, \ie enumerators declared inside of an @enum@ are visible (projected) into the enclosing scope of the @enum@ type. +enum Integral_Type integral_type = ... +printf( "%s\n", Integral_Name[@integral_type@] ); // human readable type name +\end{cfa} +However, 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}. +The need to harmonize is at best indicated by a comment before the enumeration. +This issue is exacerbated if enumeration and companion array are in different translation units. -In theory, a C enumeration \emph{variable} is an implementation-defined integral type large enough to hold all enumerated values. -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. -Finally, there is an implicit bidirectional conversion between an enumeration and its integral type. -\begin{clang} -{ - enum Weekday { /* as above */ }; $\C{// enumerators implicitly projected into local scope}$ - Weekday weekday = Mon; $\C{// weekday == 0}$ - weekday = Fri; $\C{// weekday == 11}$ - int i = Sun; $\C{// implicit conversion to int, i == 13}$ - weekday = 10000; $\C{// UNDEFINED! implicit conversion to Weekday}$ -} -int j = Wed; $\C{// ERROR! Wed is not declared in this scope}$ -\end{clang} -The implicit conversion from @int@ to an enumeration type is an unnecessary source of error. +\bigskip +While C provides a true enumeration, it is restricted, has unsafe semantics, and does provide enumeration features in other programming languages. Index: doc/theses/jiada_liang_MMath/intro.tex =================================================================== --- doc/theses/jiada_liang_MMath/intro.tex (revision 314c9d8852a35c6736a8f3ae5920e3ca35122ba7) +++ doc/theses/jiada_liang_MMath/intro.tex (revision f6321173aa4ceab077c8b556511650b082af253e) @@ -99,4 +99,5 @@ \subsection{Aliasing} +\label{s:Aliasing} Some languages provide simple secondary aliasing (renaming), \eg: Index: doc/theses/jiada_liang_MMath/relatedwork.tex =================================================================== --- doc/theses/jiada_liang_MMath/relatedwork.tex (revision 314c9d8852a35c6736a8f3ae5920e3ca35122ba7) +++ doc/theses/jiada_liang_MMath/relatedwork.tex (revision f6321173aa4ceab077c8b556511650b082af253e) @@ -18,5 +18,5 @@ \end{comment} -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}. +Enumeration-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}. Among theses languages, there are a large set of overlapping features, but each language has its own unique extensions and restrictions. @@ -24,10 +24,10 @@ \label{s:Pascal} -Classic Pascal has the \lstinline[language=pascal]{const} declaration binding a name to a constant literal/expression. +Classic Pascal has the \lstinline[language=Pascal]{const} aliasing declaration binding a name to a constant literal/expression. \begin{pascal} const one = 0 + 1; Vowels = set of (A,E,I,O,U); NULL = NIL; PI = 3.14159; Plus = '+'; Fred = 'Fred'; \end{pascal} -This mechanism is not an enumeration because there is no specific type (pseudo enumeration). +As stated, this mechanism is not an enumeration because there is no specific type (pseudo enumeration). Hence, there is no notion of a (possibly ordered) set, modulo the \lstinline[language=pascal]{set of} type. The type of each constant name (enumerator) is inferred from the constant-expression type. @@ -139,5 +139,5 @@ Ops : array( 0..3 ) of Operator; Ops := @"+-*/"@; -- string assignment to array elements -Ops := @"+-" & "*/"@; -- string concatenation and assignment +Ops := "+-" @&@ "*/"; -- string concatenation and assignment \end{ada} Ada's @Character@ type is defined as a character enumeration across all Latin-1 characters. @@ -215,30 +215,33 @@ \label{s:C++RelatedWork} -\CC has the equivalent of Pascal typed @const@ declarations \see{\VRef{s:Pascal}}, with static and dynamic initialization. +\CC enumeration is largely backwards compatible with C, so it inherited C's enumerations with some modifications and additions. + +\CC has aliasing using @const@ declarations, like C \see{\VRef{s:Cconst}}, with type inferencing, plus static/dynamic initialization. +(Note, a \CC @constexpr@ declaration is the same @const@ with the restriction that the initialization is a compile-time expression.) \begin{c++} -const auto one = 0 + 1; $\C{// static initialization}$ -const auto NULL = nullptr; -const auto PI = 3.14159; -const auto Plus = '+'; -const auto Fred = "Fred"; -const auto Mon = 0, Tue = Mon + 1, Wed = Tue + 1, Thu = Wed + 1, Fri = Thu + 1, +const @auto@ one = 0 + 1; $\C{// static initialization}$ +const @auto@ NIL = nullptr; +const @auto@ PI = 3.14159; +const @auto@ Plus = '+'; +const @auto@ Fred = "Fred"; +const @auto@ Mon = 0, Tue = Mon + 1, Wed = Tue + 1, Thu = Wed + 1, Fri = Thu + 1, Sat = Fri + 1, Sun = Sat + 1; -int sa[Sun]; -const auto r = random(); $\C{// dynamic initialization}$ -int da[r]; $\C{// VLA}$ +void foo() { + const @auto@ r = random(); $\C{// dynamic initialization}$ + int va[r]; $\C{// VLA, auto scope only}$ +} \end{c++} Statically initialized identifiers may appear in any constant-expression context, \eg @case@. -Dynamically intialized identifiers may appear as array dimensions in @g++@, which allows variable-sized arrays. -Interestingly, global \CC @const@ declarations are implicitly marked @static@ (@r@ rather than @R@). +Dynamically initialized identifiers may appear as array dimensions in @g++@, which allows variable-sized arrays. +Interestingly, global \CC @const@ declarations are implicitly marked @static@ (@r@, read-only local, rather than @R@, read-only external) \begin{c++} $\$$ nm test.o 0000000000000018 @r@ Mon \end{c++} - -\CC enumeration is largely backwards compatible with C, so it inherited C's enumerations. -However, the following non-backwards compatible changes are made. - +whereas C @const@ declarations without @static@ are marked @R@. + +The following non-backwards compatible changes are made \see{\cite[\S~7.2]{ANSI98:C++}}. \begin{cquote} -7.2 Change: \CC objects of enumeration type can only be assigned values of the same enumeration type. +Change: \CC objects of enumeration type can only be assigned values of the same enumeration type. In C, objects of enumeration type can be assigned values of any integral type. \\ Example: @@ -254,5 +257,5 @@ \begin{cquote} -7.2 Change: In \CC, the type of an enumerator is its enumeration. +Change: In \CC, the type of an enumerator is its enumeration. In C, the type of an enumerator is @int@. \\ Example: @@ -269,5 +272,4 @@ Taking the size of an enumerator is not a common C coding practice. \end{cquote} - Hence, the values in a \CC enumeration can only be its enumerators (without a cast). While the storage size of an enumerator is up to the compiler, there is still an implicit cast to @int@.