1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
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}
|
