Ignore:
Timestamp:
Apr 24, 2019, 9:31:21 PM (3 years ago)
Author:
Aaron Moss <a3moss@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr
Children:
69c37cc
Parents:
39de1c5
Message:

thesis: fix overfull hbox warnings

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/aaron_moss_PhD/phd/resolution-heuristics.tex

    r39de1c5 r5d3a952  
    4646
    4747\begin{itemize}
    48 \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!.
     48\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!.
    4949\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.
    5050\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.
     
    106106
    107107\begin{cfa}
    108 forall(otype T, otype U) void f$\(_1\)$(T, U);  $\C[3.25in]{// polymorphic}$
    109 forall(otype T) void f$\(_2\)$(T, T);  $\C[3.25in]{// less polymorphic}$
    110 forall(otype T) void f$\(_3\)$(T, int);  $\C[3.25in]{// even less polymorphic}$
    111 forall(otype T) void f$\(_4\)$(T*, int); $\C[3.25in]{// least polymorphic}$
     108forall(otype T, otype U) void f$\(_1\)$(T, U);  $\C[3.125in]{// polymorphic}$
     109forall(otype T) void f$\(_2\)$(T, T);  $\C[3.125in]{// less polymorphic}$
     110forall(otype T) void f$\(_3\)$(T, int);  $\C[3.125in]{// even less polymorphic}$
     111forall(otype T) void f$\(_4\)$(T*, int); $\C[3.125in]{// least polymorphic}$
    112112\end{cfa}
    113113
     
    196196\end{cfa}
    197197
    198 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)$.
     198In 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)$.
    199199If 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)$.
    200200However, 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.
Note: See TracChangeset for help on using the changeset viewer.