A6: WIP

2 files changed, 55 insertions, 0 deletions

diff --git a/Makefile b/Makefile
index dec781b..68f40cc 100644
--- a/Makefile
+++ b/Makefile
@@ -43,6 +43,11 @@ A5:
 	xelatex -halt-on-error -jobname=${PRE}$@ a5/exercise.tex
 	rm -f ${PRE}$@.aux ${PRE}$@.log
 
+A6:
+	xelatex -halt-on-error -jobname=${PRE}$@ a6/exercise.tex
+	xelatex -halt-on-error -jobname=${PRE}$@ a6/exercise.tex
+	rm -f ${PRE}$@.aux ${PRE}$@.log
+
 Tour3_Log:
 	xelatex -halt-on-error -jobname=${PRE}$@ tour3_log/tour3_log.tex
 	rm -f ${PRE}$@.aux ${PRE}$@.log
diff --git a/a6/exercise.tex b/a6/exercise.tex
new file mode 100644
index 0000000..2cdace6
--- /dev/null
+++ b/a6/exercise.tex
@@ -0,0 +1,50 @@
+\title{Essay: Applying contemporary C++ in applications for embedded
+microcontrollers.}
+\documentclass[11pt]{article}
+\usepackage{graphicx}
+%\usepackage{xcolor}
+\usepackage{fancyhdr}
+\usepackage{listings}
+\usepackage{subfig}
+\renewcommand{\floatpagefraction}{.8}%
+%\renewcommand{\thesubfigure}{Figure \arabic{subfigure}}
+\captionsetup[subfigure]{labelformat=simple, labelsep=colon}
+\pagestyle{fancy}
+\author{Bent Bisballe Nyeng <deva@aasimon.org> University of Aarhus}
+\begin{document}
+\maketitle
+
+No access to MMU, implicitly, prohibits calls to delete after
+initialization phase. Otherwise this will lead to memory fragmentation
+which again might lead to free-store depletion and ultimately
+application failure.
+
+Writing a custom allocator is only a solution to a sub-set of the
+allocations in an application, for example if all allocations are
+guaranteed to always be of the same size, in which can no
+fragmentation will occur.
+
+But for most applications (or at least most parts on an application)
+this is not the case, and therefore others means need to be taken into
+use.
+
+The most common way of addressing this, is simply to only use stack
+allocation, or store all objects in as static globals.
+But in certain areas of the C++ language dynamic allocation might
+occur without the developer knowing about it.
+\texttt{std::string}s of sizes that doesn't fit in the SSO buffer is
+one example, but even more devious is the capture clause of a
+lambda, which might allocate extra memory, if more than $N$ members
+are captured, where $N$ is compiler dependent.
+
+No way of telling the compiler that ``no allocations allowed, fail if
+one is made'' exists, but one could wish for such a mechanism in the
+wake of the ``free-standing C++'' subset work.
+One thing is to prohibit use of language constructs that are
+guaranteed to allocate, but quite another is to allow using constructs
+in ways that doesn't make them allocate.
+This, I think, is not part of the ``free-standing C++'' work.
+
+
+
+\end{document}