From d4d7a3a372fa64d84a48e8f0a472349cbb67b4fb Mon Sep 17 00:00:00 2001
From: Bent Bisballe Nyeng <deva@aasimon.org>
Date: Thu, 3 Aug 2023 08:06:31 +0200
Subject: A6: WIP

---
 a6/exercise.tex | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 a6/exercise.tex

(limited to 'a6')

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}
-- 
cgit v1.2.3