Changeset 5d3a952 for doc

Ignore:
Timestamp:
Apr 24, 2019, 9:31:21 PM (3 years ago)
Branches:
aaron-thesis, arm-eh, cleanup-dtors, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr
Children:
69c37cc
Parents:
39de1c5
Message:

thesis: fix overfull hbox warnings

Location:
doc/theses/aaron_moss_PhD/phd
Files:
2 edited

Legend:

Unmodified
 r39de1c5 int int_list_head( const struct int_list* ls ) { return ls->value; } $\C[\textwidth]{// all code must be duplicated for every generic instantiation}$ // all code must be duplicated for every generic instantiation struct string_list { const char* value; struct string_list* next; }; { return ls->value; } $\C[\textwidth]{// use is efficient and idiomatic}$ // use is efficient and idiomatic int main() { struct list { void* value; struct list* next; }; $\C[\textwidth]{// internal memory management requires helper functions}$ // internal memory management requires helper functions void list_insert( struct list** ls, void* x, void* (*copy)(void*) ) { void* list_head( const struct list* ls ) { return ls->value; } $\C[\textwidth]{// helpers duplicated per type}$ // helpers duplicated per type void* int_copy(void* x) { #include   $\C{// for printf}$ $\C[\textwidth]{// code is nested in macros}$ // code is nested in macros #define list(N) N ## _list define_list(string, const char*); $\C[3in]{// defines string\_list}$ $\C[\textwidth]{// use is efficient, but syntactically idiosyncratic}$ // use is efficient, but syntactically idiosyncratic int main() { forall(otype T) struct list { T value; list(T)* next; }; $\C[\textwidth]{// single polymorphic implementation of each function}$ $\C[\textwidth]{// overloading reduces need for namespace prefixes}$ // single polymorphic implementation of each function // overloading reduces need for namespace prefixes forall(otype T) void insert( list(T)** ls, T x ) { forall(otype T) T head( const list(T)* ls ) { return ls->value; } $\C[\textwidth]{// use is clear and efficient}$ // use is clear and efficient int main() {
 r39de1c5 \begin{itemize} \item If either operand is a floating-point type, the common type is the size of the largest floating-point type. If either operand is !_Complex!, the common type is also !_Complex!. \item If either operand is a floating-point type, the common type is the size of the largest floating-point type. If either operand is !_Complex!, the common type is also \linebreak !_Complex!. \item If both operands are of integral type, the common type has the same size\footnote{Technically, the C standard defines a notion of \emph{rank} in \cite[\S{}6.3.1.1]{C11}, a distinct value for each \lstinline{signed} and \lstinline{unsigned} pair; integral types of the same size thus may have distinct ranks. For instance, though \lstinline{int} and \lstinline{long} may have the same size, \lstinline{long} always has greater rank. The standard-defined types are declared to have greater rank than any types of the same size added as compiler extensions.} as the larger type. \item If the operands have opposite signedness, the common type is !signed! if the !signed! operand is strictly larger, or !unsigned! otherwise. If the operands have the same signedness, the common type shares it. \begin{cfa} forall(otype T, otype U) void f$$$_1$$$(T, U);  $\C[3.25in]{// polymorphic}$ forall(otype T) void f$$$_2$$$(T, T);  $\C[3.25in]{// less polymorphic}$ forall(otype T) void f$$$_3$$$(T, int);  $\C[3.25in]{// even less polymorphic}$ forall(otype T) void f$$$_4$$$(T*, int); $\C[3.25in]{// least polymorphic}$ forall(otype T, otype U) void f$$$_1$$$(T, U);  $\C[3.125in]{// polymorphic}$ forall(otype T) void f$$$_2$$$(T, T);  $\C[3.125in]{// less polymorphic}$ forall(otype T) void f$$$_3$$$(T, int);  $\C[3.125in]{// even less polymorphic}$ forall(otype T) void f$$$_4$$$(T*, int); $\C[3.125in]{// least polymorphic}$ \end{cfa} \end{cfa} In C semantics, this example is unambiguously upcasting !32! to !unsigned long long!, performing the shift, then downcasting the result to !unsigned!, at total cost $(1,0,3,1,0,0,0)$. In C semantics, this example is unambiguously upcasting !32! to !unsigned long long!, performing the shift, then downcasting the result to !unsigned!, at cost $(1,0,3,1,0,0,0)$. If ascription were allowed to be a first-class interpretation of a cast expression, it would be cheaper to select the !unsigned! interpretation of !?>>?! by downcasting !x! to !unsigned! and upcasting !32! to !unsigned!, at a total cost of $(1,0,1,1,0,0,0)$. However, this break from C semantics is not backwards compatibile, so to maintain C compatibility, the \CFA{} resolver selects the lowest-cost interpretation of the cast argument for which a conversion or coercion to the target type exists (upcasting to !unsigned long long! in the example above, due to the lack of unsafe downcasts), using the cost of the conversion itself only as a tie-breaker.