A6: WIP

2 files changed, 31 insertions, 24 deletions

diff --git a/Makefile b/Makefile
index c7c115d..6dde807 100644
--- a/Makefile
+++ b/Makefile
@@ -44,7 +44,11 @@ A5:
 	rm -f ${PRE}$@.aux ${PRE}$@.log
 
 A6:
+	zip ${PRE}$@.zip a4/Makefile
+	zip ${PRE}$@.zip a4/*.cc
+	zip ${PRE}$@.zip a4/*.h
 	make -C a6 ${PRE}$@.pdf
+	cp a6/${PRE}$@.pdf .
 
 Tour3_Log:
 	xelatex -halt-on-error -jobname=${PRE}$@ tour3_log/tour3_log.tex
diff --git a/a6/au_BentBisballeNyeng_A6.tex b/a6/au_BentBisballeNyeng_A6.tex
index 107e62a..6acd180 100644
--- a/a6/au_BentBisballeNyeng_A6.tex
+++ b/a6/au_BentBisballeNyeng_A6.tex
@@ -40,7 +40,7 @@ allocations (such as smart-pointers), but can still be used for
 managing other types of resources, such as locks or hardware
 peripheral access.
 
-\subsection{Dynamic Memory Allocation}
+\subsection{Dynamic Memory Allocation}\label{dyn}
 
 There can be many reasons for not allocating on the free-store, either
 by convention; ``no allocations allowed after the engines has
@@ -52,7 +52,7 @@ memory depletion\cite{weis}.
 
 In the case of memory fragmentation one might argue that it is not the
 allocation that is the problem but rather the free'ing since this is
-when the fragmentation happens. This problem is shown in
+when the fragmentation happens. The problem is shown in
 figure \ref{frag}, which might be possible to circumvent in singular
 concrete cases, but cannot be solved in general without the page
 indirections of the virtual memory\cite{weis}.
@@ -69,17 +69,19 @@ fragmentation.}}
 \label{frag}
 \end{figure}
 
-This can to some degree be prevented by monotonic allocations which
-might work for  not very practical in real-world
-software and certainly not for the dynamic allocations in the STL or
-the core-language.
+This can to some degree be prevented by monotonic allocations where
+each allocation always has the same size and therefore can be re-used
+directly after being freed. This might work for some special usecases,
+where objects of similar size are being stored in a pool may not be
+applicable in software in general and certainly not for the dynamic
+allocations in the STL or the core-language.
 
 In particular, a lambda stored in a \texttt{std::function} might
-allocate memory on the free-store if the lambda exceeds the size of
-the (compiler dependent) small-buffer optimization (SBO) buffer inside
-the \texttt{std::functions}\cite{elbeno}. In much the same way as
-the \texttt{std::string} has its small string optimization (also
-compiler dependent).
+allocate memory on the free-store if the lambda captures exceeds the
+size of the (compiler dependent) small-buffer optimization (SBO)
+buffer inside the \texttt{std::functions}\cite{elbeno}. In much the
+same way as the \texttt{std::string} has its small string optimization
+(SSO) which are also compiler dependent in size.
 
 \subsection{Free-Standing}
 
@@ -142,18 +144,18 @@ There exists a \texttt{-ffreestanding} argument, but this follows the
 old (current) definition of free-standing and as such allows
 dynamic allocation so it cannot be used.
 
-Some constructs have built-in optimizations that make them store their
-data in local members, instead of on the free-store through a pointer,
-until som limit is reached making it possible to use for
-example \texttt{std::string}s or \texttt{std::function}s as long as
-they don't require more than $N$ bytes, where $N$ is a compiler
-dependent.
+As mentiond in section \ref{dyn}, some constructs have built-in
+optimizations that make them store their data in local members,
+instead of on the free-store through a pointer, until som limit is
+reached making it possible to use for example \texttt{std::string}s
+or \texttt{std::function}s as long as they don't require more than $N$
+bytes, where $N$ is a compiler dependent.
 
-To detect if a free-store allocation is done a simple overload
+To detect if or when a free-store allocation is done a simple overload
 of \texttt{new} is made, which simply throws an exeption if called.
-This will lead to a run-time error and not a compile-time one as would
-have been the ideal solution, but at least it can assists in finding
-the $N$ for a specific compiler.
+This will lead to a run-time error and not a compile-time one, which
+would otherwise have been the ideal solution, but at least it can
+assists in finding the $N$s for a specific compiler.
 
 The code could simply look something like this:
 
@@ -164,11 +166,12 @@ void* operator new(std::size_t)
 }
 \end{lstlisting}\normalsize
 
-The code for this experiment can be found in the \texttt{noalloc.cc}
-file.
+The complete code for this experiment can be found in
+the \texttt{noalloc.cc} file.
 The following table shows the impirically deduced sizes of $N$ wherever
 SSO or SBO is available along with comments about the general component
-behaviour.\\
+behaviour. The sizes were simply increased until the compiled program
+started throwing the \texttt{std::bad\_alloc} exception.\\
 
 \noindent\begin{tabular}{| l | c | l |}
 \hline