diff options
author | Bent Bisballe Nyeng <deva@aasimon.org> | 2023-08-03 08:06:31 +0200 |
---|---|---|
committer | Bent Bisballe Nyeng <deva@aasimon.org> | 2023-08-03 08:06:31 +0200 |
commit | d4d7a3a372fa64d84a48e8f0a472349cbb67b4fb (patch) | |
tree | 9bd8bb3042067dc912d2dc91ed0231635870b9bb /a6 | |
parent | d8fea7f2b4abda430ebfe65aa65002cab2e9ce42 (diff) |
A6: WIP
Diffstat (limited to 'a6')
-rw-r--r-- | a6/exercise.tex | 50 |
1 files changed, 50 insertions, 0 deletions
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} |