\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}