diff options
| -rw-r--r-- | Makefile | 5 | ||||
| -rw-r--r-- | a6/exercise.tex | 50 |
2 files changed, 55 insertions, 0 deletions
@@ -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} |