Ignore:
Timestamp:
Apr 8, 2024, 11:56:19 AM (6 weeks ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
master
Children:
cb98d9d
Parents:
2d82999
Message:

work on Figure 2.1

Location:
doc/theses/mike_brooks_MMath
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • doc/theses/mike_brooks_MMath/background.tex

    r2d82999 rd3a49864  
    4545Hence, in all cases, @sizeof@ is informing about type information.
    4646
    47 So, thinking of an array as a pointer to its first element is too simplistic an analogue and it is not backed up the type system.
    48 This misguided analogue can be forced onto single-dimension arrays but there is no advantage other than possibly teaching beginning programmers about basic runtime array-access.
    49 
    50 Continuing, a shortened form for declaring local variables exists, provided that length information is given in the initializer:
     47So, thinking of an array as a pointer to its first element is too simplistic an analogue and it is not backed up by the type system.
     48This misguided analogue works for a single-dimension array but there is no advantage other than possibly teaching beginning programmers about basic runtime array-access.
     49
     50Continuing, a short form for declaring array variables exists using length information provided implicitly by an initializer.
    5151\lstinput{59-62}{bkgd-carray-arrty.c}
    52 In these declarations, the resulting types are both arrays, but their lengths are inferred.
    53 
    54 My contribution is enabled by recognizing
     52The compiler counts the number of initializer elements and uses this value as the first dimension.
     53Unfortunately, the implicit element counting does not extend to dimensions beyond the first.
     54\lstinput{64-67}{bkgd-carray-arrty.c}
     55
     56My contribution is recognizing:
    5557\begin{itemize}
    56         \item There is value in using a type that knows how big the whole thing is.
     58        \item There is value in using a type that knows its size.
    5759        \item The type pointer to (first) element does not.
    5860        \item C \emph{has} a type that knows the whole picture: array, e.g. @T[10]@.
    59         \item This type has all the usual derived forms, which also know the whole picture.  A usefully noteworthy example is pointer to array, e.g. @T(*)[10]@.
     61        \item This type has all the usual derived forms, which also know the whole picture.
     62        A usefully noteworthy example is pointer to array, e.g. @T (*)[10]@.\footnote{
     63        The parenthesis are necessary because subscript has higher priority than pointer in C declarations.
     64        (Subscript also has higher priority than dereference in C expressions.)}
    6065\end{itemize}
    6166
    62 Each of these sections, which introduces another layer of of the C arrays' story,
    63 concludes with an \emph{Unfortunate Syntactic Reference}.
    64 It shows how to spell the types under discussion,
    65 along with interactions with orthogonal (but easily confused) language features.
     67The following sections introduce the many layers of the C array story, concluding with an \emph{Unfortunate Syntactic Reference}.
     68It shows how to define (spell) the types under discussion, along with interactions with orthogonal (but easily confused) language features.
    6669Alternate spellings are listed within a row.
    6770The simplest occurrences of types distinguished in the preceding discussion are marked with $\triangleright$.
    … …  
    7881for the example of letting @x@ be a \emph{pointer to array}, the declaration is spelled:
    7982\begin{cfa}
    80 [ * [10] T ] x;
     83* [10] T x;
    8184\end{cfa}
    8285The \CFA-Full column gives the spelling of a different type, introduced in TODO, which has all of my contributed improvements for safety and ergonomics.
     86
     87Another example of confusion results from the fact that a routine name and its parameters are embedded within the return type, mimicking the way the return value is used at the routine's call site.
     88For example, a routine returning a \Index{pointer} to an array of integers is defined and used in the following way:
     89\begin{cfa}
     90int @(*@f@())[@5@]@ {...}; $\C{// definition}$
     91 ... @(*@f@())[@3@]@ += 1; $\C{// usage}$
     92\end{cfa}
     93Essentially, the return type is wrapped around the routine name in successive layers (like an \Index{onion}).
     94While attempting to make the two contexts consistent is a laudable goal, it has not worked out in practice, even though Dennis Richie believed otherwise:
     95\begin{quote}
     96In spite of its difficulties, I believe that the C's approach to declarations remains plausible, and am comfortable with it; it is a useful unifying principle.~\cite[p.~12]{Ritchie93}
     97\end{quote}
     98
     99\CFA provides its own type, variable and routine declarations, using a different syntax.
     100The new declarations place qualifiers to the left of the base type, while C declarations place qualifiers to the right of the base type.
     101In the following example, {\color{red}red} is the base type and {\color{blue}blue} is qualifiers.
     102The \CFA declarations move the qualifiers to the left of the base type, \ie move the blue to the left of the red, while the qualifiers have the same meaning but are ordered left to right to specify a variable's type.
     103\begin{cquote}
     104\begin{tabular}{@{}l@{\hspace{3em}}l@{}}
     105\multicolumn{1}{c@{\hspace{3em}}}{\textbf{C}}   & \multicolumn{1}{c}{\textbf{\CFA}}     \\
     106\begin{cfa}[moredelim={**[is][\color{blue}]{\#}{\#}}]
     107@int@ #*# x1 #[5]#;
     108@int@ #(*#x2#)[5]#;
     109#int (*#f@( int p )@#)[5]#;
     110\end{cfa}
     111&
     112\begin{cfa}[moredelim={**[is][\color{blue}]{\#}{\#}}]
     113#[5] *# @int@ x1;
     114#* [5]# @int@ x2;
     115#[* [5] int]# f@( int p )@;
     116\end{cfa}
     117\end{tabular}
     118\end{cquote}
    83119
    84120\VRef[Figure]{bkgd:ar:usr:avp} gives this reference for the discussion so far.
    … …  
    87123\centering
    88124\setlength{\tabcolsep}{3pt}
    89 \begin{tabular}{llllll}
    90         & Description & Type & Declaration & \CFA-C  & \CFA-Full \\ \hline
    91         $\triangleright$ & val.
    92             & @T@
    93             & @T x;@
    94             & @[ T ]@
    95             &
    96             \\ \hline
    97         & \pbox{20cm}{ \vspace{2pt} val.\\ \footnotesize{no writing the val.\ in \lstinline{x}}   }\vspace{2pt}
    98             & \pbox{20cm}{ \vspace{2pt} \lstinline{const T} \\ \lstinline{T const}   }
    99             & \pbox{20cm}{ \vspace{2pt} \lstinline{const T x;} \\ \lstinline{T const x;}   }
    100             & @[ const T ]@
    101             &
    102             \\ \hline \hline
    103         $\triangleright$ & ptr.\ to val.
    104             & @T *@
    105             & @T * x;@
    106             & @[ * T ]@
    107             &
    108             \\ \hline
    109         & \pbox{20cm}{ \vspace{2pt} ptr.\ to val.\\ \footnotesize{no writing the ptr.\ in \lstinline{x}}   }\vspace{2pt}
    110             & @T * const@
    111             & @T * const x;@
    112             & @[ const * T ]@
    113             &
    114             \\ \hline
    115         & \pbox{20cm}{ \vspace{2pt} ptr.\ to val.\\ \footnotesize{no writing the val.\ in \lstinline{*x}}   }\vspace{2pt}
    116             & \pbox{20cm}{ \vspace{2pt} \lstinline{const T *} \\ \lstinline{T const *}   }
    117             & \pbox{20cm}{ \vspace{2pt} \lstinline{const T * x;} \\ \lstinline{T const * x;}   }
    118             & @[ * const T ]@
    119             &
    120             \\ \hline \hline
    121         $\triangleright$ & ar.\ of val.
    122             & @T[10]@
    123             & @T x[10];@
    124             & @[ [10] T ]@
    125             & @[ array(T, 10) ]@
    126             \\ \hline
    127         & \pbox{20cm}{ \vspace{2pt} ar.\ of val.\\ \footnotesize{no writing the val.\ in \lstinline{x[5]}}   }\vspace{2pt}
    128             & \pbox{20cm}{ \vspace{2pt} \lstinline{const T[10]} \\ \lstinline{T const[10]}   }
    129             & \pbox{20cm}{ \vspace{2pt} \lstinline{const T x[10];} \\ \lstinline{T const x[10];}   }
    130             & @[ [10] const T ]@
    131             & @[ const array(T, 10) ]@
    132             \\ \hline
    133         & ar.\ of ptr.\ to val.
    134             & @T*[10]@
    135             & @T *x[10];@
    136             & @[ [10] * T ]@
    137             & @[ array(* T, 10) ]@
    138             \\ \hline
    139         & \pbox{20cm}{ \vspace{2pt} ar.\ of ptr.\ to val.\\ \footnotesize{no writing the ptr.\ in \lstinline{x[5]}}   }\vspace{2pt}
    140             & @T * const [10]@
    141             & @T * const x[10];@
    142             & @[ [10] const * T ]@
    143             & @[ array(const * T, 10) ]@
    144             \\ \hline
    145         & \pbox{20cm}{ \vspace{2pt} ar.\ of ptr.\ to val.\\ \footnotesize{no writing the val.\ in \lstinline{*(x[5])}}   }\vspace{2pt}
    146             & \pbox{20cm}{ \vspace{2pt} \lstinline{const T * [10]} \\ \lstinline{T const * [10]}   }
    147             & \pbox{20cm}{ \vspace{2pt} \lstinline{const T * x[10];} \\ \lstinline{T const * x[10];}   }
    148             & @[ [10] * const T ]@
    149             & @[ array(* const T, 10) ]@
    150             \\ \hline \hline
    151         $\triangleright$ & ptr.\ to ar.\ of val.
    152             & @T(*)[10]@
    153             & @T (*x)[10];@
    154             & @[ * [10] T ]@
    155             & @[ * array(T, 10) ]@
    156             \\ \hline
    157         & \pbox{20cm}{ \vspace{2pt} ptr.\ to ar.\ of val.\\ \footnotesize{no writing the ptr.\ in \lstinline{x}}   }\vspace{2pt}
    158             & @T(* const)[10]@
    159             & @T (* const x)[10];@
    160             & @[ const * [10] T ]@
    161             & @[ const * array(T, 10) ]@
    162             \\ \hline
    163         & \pbox{20cm}{ \vspace{2pt} ptr.\ to ar.\ of val.\\ \footnotesize{no writing the val.\ in \lstinline{(*x)[5]}}   }\vspace{2pt}
    164             & \pbox{20cm}{ \vspace{2pt} \lstinline{const T(*)[10]} \\ \lstinline{T const (*) [10]}   }
    165             & \pbox{20cm}{ \vspace{2pt} \lstinline{const T (*x)[10];} \\ \lstinline{T const (*x)[10];}   }
    166             & @[ * [10] const T ]@
    167             & @[ * const array(T, 10) ]@
    168             \\ \hline
    169         & ptr.\ to ar.\ of ptr.\ to val.
    170             & @T*(*)[10]@
    171             & @T *(*x)[10];@
    172             & @[ * [10] * T ]@
    173             & @[ * array(* T, 10) ]@
    174             \\ \hline
     125\begin{tabular}{ll|l|l|l|l}
     126        & Description & Type & Declaration & \CFA  & \CFA-thesis \\ \hline
     127        $\triangleright$ & val. & @T@ & @T x;@ & @T@ & \\
     128        \hline
     129        & immutable val. & @const T@ & @T const x;@ & @const T@ & \\
     130        & & @T const@ & @T const x;@ & @T const@ & \\
     131        \hline \hline
     132        $\triangleright$ & ptr.\ to val. & @T *@ & @T * x;@ & @* T@ & \\
     133        \hline
     134        & immutable ptr. to val. & @T * const@ & @T * const x;@ & @const * T@ & \\
     135        \hline
     136        & ptr. to immutable val. & @const T *@ & @const T * x;@ & @* const T@ & \\
     137        & & @T const *@ & @T const * x;@ & @* T const@ & \\
     138        \hline \hline
     139        $\triangleright$ & ar.\ of val. & @T[10]@ & @T x[10];@ & @[10] T@ & @array(T, 10)@ \\
     140        \hline
     141        & ar.\ of immutable val. & @const T[10]@ & @const T x[10];@ & @[10] const T@ & @const array(T, 10)@ \\
     142    & & @T const [10]@ & @T const x[10];@ & @[10] T const@ & @array(T, 10) const@ \\
     143        \hline
     144        & ar.\ of ptr.\ to val. & @T * [10]@ & @T * x[10];@ & @[10] * T@ & @array(T * | * T, 10)@ \\
     145        \hline
     146        & ar.\ of imm. ptr.\ to val. & @T * const [10]@ & @T * const x[10];@ & @[10] const * T@ & @array(const * T, 10)@ \\
     147        \hline
     148        & ar.\ of ptr.\ to imm. val. & @const T * [10]@ & @const T * x[10];@ & @[10] * const T@ & @array(* const T, 10)@ \\
     149        & & @T const * [10]@ & @T const * x[10];@ & @[10] * T const@ & @array(* T const, 10)@ \\
     150        \hline \hline
     151        $\triangleright$ & ptr.\ to ar.\ of val. & @T(*)[10]@ & @T (*x)[10];@ & @* [10] T@ & @* array(T, 10)@ \\
     152        \hline
     153        & imm. ptr.\ to ar.\ of val. & @T(* const)[10]@ & @T (* const x)[10];@ & @const * [10] T@ & @const * array(T, 10)@ \\
     154        \hline
     155        & ptr.\ to ar.\ of imm. val. & @const T(*)[10]@ & @const T (*x)[10];@ & @* [10] const T@ & @* const array(T, 10)@ \\
     156        & & @T const (*) [10]}@ & @T const (*x)[10];@ & @* [10] T const@ & @* array(T, 10) const@ \\
     157        \hline
     158        & ptr.\ to ar.\ of ptr.\ to val. & @T*(*)[10]@ & @T *(*x)[10];@ & @* [10] * T@ & @* array(T * | * T, 10)@ \\
     159        \hline
    175160\end{tabular}
    176161\caption{Unfortunate Syntactic Reference for Array vs Pointer.  Includes interaction with constness.}
    … …  
    251236ARM-6.7.6.3.7 explains that when an array type is written for a parameter,
    252237the parameter's type becomes a type that I summarize as being the array-decayed type.
    253 The respective handlings of the following two parameter spellings shows that the array-spelled one is really, like the other, a pointer.
     238The respective handling of the following two parameter spellings shows that the array-spelled one is really, like the other, a pointer.
    254239\lstinput{12-16}{bkgd-carray-decay.c}
    255240As the @sizeof(x)@ meaning changed, compared with when run on a similarly-spelled local variable declaration,
    … …  
    284269\lstinput{32-42}{bkgd-carray-decay.c}
    285270
    286 \VRef[Figure]{bkgd:ar:usr:decay-parm} gives the reference for the decay phenomenon seen in parameter decalarations.
     271\VRef[Figure]{bkgd:ar:usr:decay-parm} gives the reference for the decay phenomenon seen in parameter declarations.
    287272
    288273\begin{figure}

  • doc/theses/mike_brooks_MMath/programs/bkgd-carray-arrty.c

    r2d82999 rd3a49864  
    5757        f( &ar );
    5858
    59         float fs[] = {3.14, 1.707};
     59        float fs[] = {3.14, 1.77};
    6060        char cs[] = "hello";
    6161        static_assert( sizeof(fs) == 2 * sizeof(float) );
    6262        static_assert( sizeof(cs) == 6 * sizeof(char) );  $\C{// 5 letters + 1 null terminator}$
    6363
     64        float fm[][2] = { {3.14, 1.77}, {12.4, 0.01}, {7.8, 1.23} };  $\C{// brackets define structuring}$
     65        char cm[][sizeof("hello")] = { "hello", "hello", "hello" };
     66        static_assert( sizeof(fm) == 3 * 2 * sizeof(float) );
     67        static_assert( sizeof(cm) == 3 * 6 * sizeof(char) );
    6468}
    6569
Note: See TracChangeset for help on using the changeset viewer.