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

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

(limited to 'a5/exercise.tex')

diff --git a/a5/exercise.tex b/a5/exercise.tex
new file mode 100644
index 0000000..6889950
--- /dev/null
+++ b/a5/exercise.tex
@@ -0,0 +1,63 @@
+\title{A5: Generic Programming}
+\input{preamble.tex}
+
+I decided to use std container for the elements of the matrix and
+initially went with \texttt{std::vector<int>}. But since we were going
+to do arithmentics on the data, and no requirements were made as to
+the arithmentics actually being those of a real matrix, I figure why
+not use \texttt{std::valarray<int>} and have all arithmentic
+operations be per-entry, re-suing the behaviour of
+\texttt{std::valarray} directly.
+
+In the change I discovered that \texttt{std::valarray} and
+\texttt{std::vector} ctor args for creating with a size and a default
+value for all items are reversed, which would not be caught by the
+compiler with both of them being integral:
+\footnotesize\begin{lstlisting}[language=C++]
+explicit vector( size_type count,
+                 const T& value = T(),
+                 const Allocator& alloc = Allocator() );
+
+valarray( const T& val, std::size_t count );
+\end{lstlisting}\normalsize
+That, I think, is rather unfortunate.
+
+When using a std container, all memory managing is handled by the
+container, even when throwing an exception inside the constructor, so
+no need to do anything clever inside the matrix implementation itself.
+
+I first wrote the entire \texttt{Imatrix} class with the values
+dynamically allocated inside the \texttt{std::valarray} but wanted to
+explore having the matrix dimenions available at compile-time
+(matrices doesn't have the habit of changing their sizes dynamically,
+so they should be checkable at compile-time). I did this with template
+size arguments.
+
+This removed a lot of error checks on matrix dimension matching, which
+is part of the type itself - nice!
+
+It also removed the need for the two integer members carrying the
+width and height - we now also saved 16 bytes of memory!
+
+... and we get a compile error if for example we try multiplying two
+matrices where their dimensions doesn't adhere to the algebraic rules!
+
+Final step is to templatize the underlying typeof the matrix. Done so
+by simply replacing int with T and all the places where 0 is assigned
+to the value type, replacing it with the default value T{}
+
+When instantiating a template only the required/used functions are
+generated (or so it appears).
+In other words, I can instante a \texttt{Matrix<Chess\_piece,2,2> c1}
+without getting any compile errors because I don't actually call
+anything on it.
+If I add a \texttt{c1 + 1} somewhere it will complain about not being
+able to add, but not any of the other unused operations.
+When adding the requirements of concepts, I will get errors for all
+the uses, not just the ones I use. In other words, concepts might end
+up requirering more work to be done by a developer than strictly
+needed. This I think is actually not that good.
+Adding the requirement to each of the member functions might be
+better.
+
+\end{document}
-- 
cgit v1.2.3