Changeset 4ae83a4b for doc/generic_types
- Timestamp:
- Apr 17, 2017, 3:47:12 PM (7 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- 43a284c, 9a9a5c4, e39241b
- Parents:
- c87cd93 (diff), 2183e12 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the(diff)
links above to see all the changes relative to each parent. - Location:
- doc/generic_types
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/generic_types/.gitignore
rc87cd93 r4ae83a4b 17 17 *.synctex.gz 18 18 comment.cut 19 timing.tex -
doc/generic_types/generic_types.tex
rc87cd93 r4ae83a4b 214 214 A design advantage is that, unlike \CC template-functions, \CFA polymorphic-functions are compatible with C \emph{separate compilation}, preventing compilation and code bloat. 215 215 216 Since bare polymorphic-types provide a restricted set of available operations, \CFA provides a \emph{type assertion}~\cite {alphard} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type-variable.216 Since bare polymorphic-types provide a restricted set of available operations, \CFA provides a \emph{type assertion}~\cite[pp.~37-44]{Alphard} mechanism to provide further type information, where type assertions may be variable or function declarations that depend on a polymorphic type-variable. 217 217 For example, the function @twice@ can be defined using the \CFA syntax for operator overloading: 218 218 \newpage … … 280 280 \lstDeleteShortInline@% 281 281 \par\smallskip 282 \begin{tabular}{@{}l@{\hspace{ \parindent}}|@{\hspace{\parindent}}l@{}}282 \begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}} 283 283 \begin{lstlisting} 284 284 short int MAX = ...; … … 587 587 \lstDeleteShortInline@% 588 588 \par\smallskip 589 \begin{tabular}{@{}l@{\hspace{ \parindent}}|@{\hspace{\parindent}}l@{}}589 \begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}} 590 590 \begin{lstlisting} 591 591 int f( int, int ); … … 616 616 \lstDeleteShortInline@% 617 617 \par\smallskip 618 \begin{tabular}{@{}l@{\hspace{ \parindent}}|@{\hspace{\parindent}}l@{}}618 \begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}} 619 619 \begin{lstlisting} 620 620 int x = 10; … … 658 658 \lstDeleteShortInline@% 659 659 \par\smallskip 660 \begin{tabular}{@{}l@{\hspace{ \parindent}}|@{\hspace{\parindent}}l@{}}660 \begin{tabular}{@{}l@{\hspace{1.5\parindent}}||@{\hspace{1.5\parindent}}l@{}} 661 661 \begin{lstlisting} 662 662 [int, int, long, double] x; … … 1019 1019 \end{table} 1020 1020 1021 The C and \CCV variants are generally the slowest with the largest memory footprint, because totheir less-efficient memory layout and the pointer-indirection necessary to implement generic types;1021 The C and \CCV variants are generally the slowest with the largest memory footprint, because of their less-efficient memory layout and the pointer-indirection necessary to implement generic types; 1022 1022 this inefficiency is exacerbated by the second level of generic types in the pair-based benchmarks. 1023 1023 By contrast, the \CFA and \CC variants run in roughly equivalent time for both the integer and pair of @_Bool@ and @char@ because the storage layout is equivalent.
Note: See TracChangeset
for help on using the changeset viewer.